Query statement generation method and device, electronic equipment and storage medium

Abstract

The application provides a query statement generation method and device, electronic equipment and storage medium, relates to the field of artificial intelligence, in particular to the fields of computer, database and deep learning. The query statement generation method comprises: performing intent recognition on a demand text based on business data to obtain a demand intent; in response to the demand intent meeting a preset demand condition, processing the demand intent by using a language model to obtain an execution logic structure, the execution logic structure comprising a plurality of execution logic elements based on a structured representation, and a structured relationship between the plurality of execution logic elements representing an execution process of an execution query statement; determining target schema information matched with a text semantic represented by the execution logic elements from preset database schema information; performing semantic understanding on the plurality of execution logic elements and the target schema information by using the language model to output a plurality of intermediate structured data for describing the query statement; and generating the query statement according to the intermediate structured data.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, specifically to the fields of computer science, databases, and deep learning, and more specifically to a query statement generation method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the rapid development of artificial intelligence (AI) technology, querying data in databases can be accomplished with the assistance of AI, thereby improving business service response efficiency. However, AI-assisted database querying may also result in higher error rates and query failures, thus impacting the user experience. Summary of the Invention

[0003] In view of the above problems, this application provides a query statement generation method, apparatus, electronic device and storage medium.

[0004] According to a first aspect of this application, a query statement generation method is provided, comprising: performing intent recognition on a requirement text based on business data to obtain a requirement intent; responding to the requirement intent satisfying a preset requirement condition, processing the requirement intent using a language model to obtain an execution logic structure, the execution logic structure including multiple execution logic elements based on structured representation, the execution logic elements representing the target task of executing the query statement or target metadata related to the target task based on text semantics, and the structured relationship between the multiple execution logic elements representing the execution process of executing the query statement; determining target pattern information from preset database pattern information that matches the text semantics represented by the execution logic elements; using the language model to perform semantic understanding on the multiple execution logic elements and the target pattern information, outputting multiple intermediate structured data for describing the query statement; and generating the query statement based on the multiple intermediate structured data.

[0005] A second aspect of this application provides a query statement generation apparatus, comprising: an identification module for identifying the intent of a requirement text based on business data to obtain a requirement intent; an execution logic structure acquisition module for processing the requirement intent using a language model in response to the requirement intent satisfying preset requirement conditions to obtain an execution logic structure, wherein the execution logic structure includes multiple execution logic elements based on structured representation, wherein the execution logic elements represent the target task of executing the query statement or target metadata related to the target task based on text semantics, and the structured relationship between the multiple execution logic elements represents the execution process of executing the query statement; a target pattern information acquisition module for determining target pattern information matching the text semantics represented by the execution logic elements from preset database pattern information; an intermediate structured data acquisition module for using the language model to perform semantic understanding on the multiple execution logic elements and the target pattern information to output multiple intermediate structured data for describing the query statement; and a query statement generation module for generating the query statement based on the multiple intermediate structured data.

[0006] A third aspect of this application provides an electronic device, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the query statement generation method described above.

[0007] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, wherein the computer program or instructions, when executed by a processor, implement the steps of the query statement generation method described above.

[0008] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the query statement generation method described above.

[0009] According to embodiments of this application, multiple target tasks corresponding to a query statement are represented by the textual semantics of multiple execution logic elements in the execution logic structure, and the execution logic between multiple target tasks is represented based on the structured relationship between the execution logic elements. This structurally and clearly characterizes the execution process of a query statement matching the execution requirement text through textual semantics. Furthermore, by determining the target pattern information matching the execution logic elements and performing semantic understanding of the execution logic elements and target pattern information based on a language model, the objects represented by database schema information such as tables, columns, and indexes required to execute the target tasks are clearly determined. This ensures that the output intermediate structured data accurately represents the multiple target tasks in the query statement and matches the logical process of the target tasks with the tables, columns, and other objects in the database. This avoids the output query statement operating on irrelevant or incorrect database objects due to illusions caused by the language model, thus improving the accuracy of the query statement generated based on the intermediate structured data and increasing the response speed of business services implemented through the execution of the query statement. Attached Figure Description

[0010] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0011] Figure 1 The diagram illustrates an application scenario of the query statement generation method according to an embodiment of this application.

[0012] Figure 2 A flowchart of a query statement generation method according to an embodiment of this application is shown.

[0013] Figure 3 A schematic diagram of the thought process topology according to an embodiment of this application is shown.

[0014] Figure 4 A schematic diagram of the execution logic structure according to an embodiment of this application is shown.

[0015] Figure 5 A schematic diagram of a query statement generation method according to an embodiment of this application is shown.

[0016] Figure 6 A structural diagram of the query statement transformation link and the verification link according to an embodiment of this application is shown.

[0017] Figure 7 A schematic diagram of a checkpoint according to an embodiment of this application is shown.

[0018] Figure 8 A structural block diagram of a query statement generation apparatus according to an embodiment of this application is shown.

[0019] Figure 9 A block diagram of an electronic device suitable for implementing a query statement generation method according to an embodiment of this application is shown. Detailed Implementation

[0020] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0021] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0022] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0023] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0024] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws and standards, take necessary encryption measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0025] With the rapid development of artificial intelligence technology, large language models can be used to semantically understand natural language and output query statements. This can reduce the time and workload for professionals to write query statements using programming languages, and improve the response efficiency of diverse business services such as product transactions and information inquiries. However, query statements output by large language models are difficult to accurately adapt to business service needs, and errors in query statement generation can easily lead to reduced business service response efficiency, making it difficult to meet actual business service requirements.

[0026] This application provides a query statement generation method, apparatus, electronic device, and storage medium. The query statement generation method includes: performing intent recognition on requirement text based on business data to obtain requirement intent; responding to the requirement intent satisfying preset requirement conditions, processing the requirement intent using a language model to obtain an execution logic structure, the execution logic structure including multiple execution logic elements based on structured representation, each execution logic element representing the target task or target metadata related to the target task based on text semantics, and the structured relationship between the multiple execution logic elements representing the execution process of the query statement; determining target pattern information from preset database pattern information that matches the text semantics represented by the execution logic elements; using a language model to perform semantic understanding on the multiple execution logic elements and target pattern information, outputting multiple intermediate structured data to describe the query statement; and generating a query statement based on the multiple intermediate structured data.

[0027] According to embodiments of this application, by identifying the intent of the requirement text and processing the intent through a language model to obtain the execution logic structure, the textual semantics of multiple execution logic elements in the execution logic structure can represent multiple target tasks corresponding to the query statement, and the execution logic between multiple target tasks can be represented based on the structured relationship between the execution logic elements. Thus, the execution logic structure can structurally and clearly characterize the execution process of the query statement matching the execution requirement text through textual semantics. Furthermore, by determining the target pattern information matching the execution logic elements and performing semantic understanding of the execution logic elements and target pattern information based on the language model, the objects represented by database schema information such as tables, columns, and indexes required to execute the target tasks can be clearly determined. This allows the output intermediate structured data to accurately represent multiple target tasks in the execution query statement and match the logical process of the target tasks with the tables, columns, and other objects in the database. Therefore, query statements can be generated based on multiple intermediate structured data to match the actual needs of editing query statements in the requirement text, avoiding the output query statement operating on irrelevant or incorrect database objects due to language model illusions, improving the accuracy of the query statement, and increasing the response speed of business services implemented through the execution of query statements.

[0028] Figure 1 The diagram illustrates an application scenario of the query statement generation method according to an embodiment of this application.

[0029] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0030] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0031] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0032] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0033] It should be noted that the query statement generation method provided in this application embodiment can generally be executed by server 105. Correspondingly, the query statement generation device provided in this application embodiment can generally be located in server 105. The query statement generation method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the query statement generation device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0034] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0035] Figure 2 A flowchart of a query statement generation method according to an embodiment of this application is shown.

[0036] like Figure 2 As shown, the query statement generation method of this embodiment includes operations S210 to S250.

[0037] In operation S210, intent recognition is performed on the requirement text based on business data to obtain the requirement intent.

[0038] According to embodiments of this application, the request text can be text based on natural language description input by a user through a terminal device. For example, a user can input the request text by performing interactive operations such as voice interaction or touch interaction through a smartphone.

[0039] According to embodiments of this application, business data can be data related to the type of business indicated by the user who inputs the demand text. For example, if the business service targeted by the user is a smartphone service, and the user inputs "How long will it take for xx to arrive?", the demand text can be used to identify intent based on logistics data and sales data related to the smartphone model "xx".

[0040] In some embodiments, the demand intent can be information such as text or symbols that represent the semantic attributes of the demand in the demand text. For example, the demand intent can be the demand keywords obtained by extracting keywords from the demand text.

[0041] In some embodiments, a large language model can be used to perform intent recognition on the requirement text based on business data to obtain the requirement intent. By using a large language model to process the requirement text and output the requirement intent, the requirement intent can more accurately represent the requirement attributes of the semantic representation of the requirement text, thereby further improving the matching degree between the subsequent execution logic structure and the requirement represented by the requirement text.

[0042] In operation S220, in response to the demand intent and to meet the preset demand conditions, the demand intent is processed using a language model to obtain the execution logic structure.

[0043] According to embodiments of this application, preset demand conditions may indicate that the semantic complexity of the demand intent representation meets preset complexity conditions, or may indicate that the semantic clarity and semantic logical coherence of the demand intent representation meet preset quality conditions. For example, preset demand conditions may also indicate that the product or business service type matching the demand intent matches the business attributes of the business data in the database. Embodiments of this application do not limit the specific type of preset demand conditions; those skilled in the art can design them based on actual needs.

[0044] According to embodiments of this application, the language model can be a trained Large Language Model (LLM). A Large Language Model can have a large number of model parameters and be constructed based on a deep learning model algorithm. The Large Language Model can perform semantic understanding of textual content such as intent based on its large number of model parameters, in order to generate text, code, files, and other content that match the training target or the target indicated by the prompt information.

[0045] It should be noted that the language model or large language model involved in the embodiments of this application can be uniformly represented as a large model with a large parameter scale. The large model can perform data processing tasks and output execution results by processing multimodal information such as images and text.

[0046] According to embodiments of this application, the execution logic structure includes multiple execution logic elements based on structured representation. These execution logic elements represent the target task of the query statement or target metadata related to the target task based on textual semantic representation. For example, execution logic elements can be text indicating the type of operation performed in the target task of the query statement, such as select, delete, or sum. As another example, execution logic elements can be text representing the execution conditions of the target task, such as "Area A" or "January 2020," indicating time or geographical region. Furthermore, execution logic elements can also be text related to the target metadata indicated by the target task in the query statement, such as "Brand A," "Mobile Phone," or "Sales Volume."

[0047] According to embodiments of this application, the execution logic structure is represented based on multiple execution elements and the structured relationships between them. Execution logic elements can be represented based on text such as Chinese or English, and the structured relationships between multiple execution logic elements characterize the execution process of the query statement. The structured relationships can be represented based on the textual grammatical relationships between multiple statements or words in the text. For example, multiple different execution logic elements can be represented based on multiple paragraphs. Alternatively, the topic content corresponding to multiple paragraphs can be used as execution logic elements to represent the grammatical structural relationships between the topic content and the execution logic elements in the text of the related multiple paragraphs.

[0048] Alternatively, structured relationships can be represented based on edge relationships in a topological graph. For example, the execution logic structure can be a tree topology, and the execution logic elements can be multiple nodes with edge relationships in the tree topology. The edge relationships between nodes represent the structured relationships between the execution logic elements. Each branch sub-topology in the tree topology can represent the parallel execution process of multiple target tasks in a query statement.

[0049] In operation S230, target pattern information that matches the text semantics represented by the execution logic element is determined from the preset database pattern information.

[0050] According to embodiments of this application, preset database schema information can be used to describe data tables in the database, data fields contained in the data tables, data data types of the data fields, mapping relationships between primary keys and foreign keys, indexes, constraints, and other business data-related information. Preset database schema information may include preset metadata fields such as data table name fields, column identifier fields in the data tables, and index fields; alternatively, preset database schema information may also include preset fields related to functions, operators, identifiers, and other operations that can be executed by the query statement.

[0051] In some embodiments, target schema information can be determined by semantically matching the execution logic element with fields in the preset database model information. For example, for the execution logic element "sales amount", the target metadata field "orders.amount" can be determined as the target schema information from the preset database schema information. The target metadata field "orders.amount" represents the table name of the data table in the database corresponding to the sales order.

[0052] In operation S240, a language model is used to perform semantic understanding on multiple execution logic elements and target pattern information, and output multiple intermediate structured data to describe the query statement.

[0053] In some embodiments, intermediate structured data is used to describe the target task in the query statement based on a structured format language. The arrangement relationship, hierarchical relationship, and other attribute information representing the structured relationship among multiple intermediate structured data can represent the execution logic between multiple target tasks.

[0054] According to embodiments of this application, the intermediate structured data can describe the query statement according to a preset configuration format, rather than generating the query statement's execution result by directly executing the intermediate structured data. For example, it can be represented based on preset configuration formats such as JSON, YAML, or XML. Embodiments of this application do not limit the specific format type of the intermediate structured data, as long as it can describe the target task in the query statement.

[0055] In some embodiments, the intermediate structured data may include target schema information with binding relationships (or dependencies, mapping relationships) and execution logic elements represented based on a preset configuration format. For example, the intermediate structured data may be sum(A1 and B1), where "sum" is an execution logic element represented based on a preset configuration format, and "A1" and "B1" are data table name fields serving as target schema information.

[0056] In operation S250, a query statement is generated based on multiple intermediate structured data.

[0057] In some embodiments, intermediate structured data can be data fields represented in a structured Domain-Specific Language (DSL) format. The intermediate structured data uses structured JSON data fields to represent the execution logic of the target task in the query statement. Thus, the execution process of the query statement can be described using multiple intermediate structured data sets, facilitating the processing of these sets by query statement builders and other related tools to generate a query statement that matches the intent of the request text.

[0058] According to embodiments of this application, by representing execution logic elements based on text and representing the textual syntactic relationships between multiple execution logic elements based on structured relationships, the execution logic process of multiple target tasks in a query statement can be represented more accurately and clearly based on the textual semantic logic represented by the execution logic structure. This allows the language model to semantically understand the multiple execution logic elements and structured relationships within the execution logic structure, thus clearly transforming the execution process of multiple target tasks in the query statement into multiple intermediate structured data that can describe the query statement. This avoids comprehension errors caused by the language model interpreting natural language and converting it into the code content of the query statement. Furthermore, understanding the matching target pattern information and execution logic elements through the language model avoids situations where the operation fields and metadata fields in the intermediate structured data output by the language model do not match, or even create the illusion that metadata fields such as table names and column names do not exist in the database. This enables the query statement generated based on multiple intermediate structured data to more accurately represent the actual intent of the user's input text, improving query generation efficiency and business service response efficiency.

[0059] In some embodiments, generating a query statement based on multiple intermediate structured data may include: using a language model to process multiple intermediate structured data represented by domain-specific language format attributes to generate a query statement.

[0060] According to embodiments of this application, query statements are generated by using a language model to process multiple intermediate structured data represented by domain-specific language format attributes. This leverages the large model parameter scale and powerful semantic understanding capabilities of the language model to understand the execution process of the query statements represented by the multiple intermediate structured data, resulting in more accurate query statements. This improves the efficiency and accuracy of query statement generation, thereby enhancing the response efficiency of business services through query statement execution.

[0061] In one example, the demand text is "Products in region A or region B that have a rating below 3 stars or a return rate exceeding 10% in the mobile phone category." By processing the demand text using a language model, multiple keywords are obtained: region A, region B, mobile phone, rating below 3 stars, and return rate exceeding 10%, serving as multiple demand intents. By processing these multiple demand intents using a language model, an execution logic structure based on structured text representation is output. By further processing the execution logic structure and target pattern information matching the execution logic elements using a language model, intermediate structured data based on domain-specific language format attributes, enclosed in the symbol " / / ", can be output as follows:

[0062] / / {"operation": "SELECT","columns": [{"name": "product_name", "alias": "product name"},{"name": "region", "alias": "region"},{"name": "avg_rating", "alias": "average rating"},{"name": "return_rate", "alias": "return rate"}] / / .

[0063] / / "from": {"primary_table": "products","joins": [{"type": "INNERJOIN", "table": "sales_stats", "on": "products.id = sales_stats.product_id"},{"type": "INNER JOIN", "table": "regions", "on": "sales_stats.region_id =regions.id"}]} / / .

[0064] / / "where": ["(regions.name IN ('A region', 'B region'))","products.category= 'mobile phone'","(sales_stats.avg_rating < 3 OR sales_stats.return_rate > 0.1)"]} / / .

[0065] Here, "from": {"primary_table": "products" can represent intermediate structured data, where "from" can be an identifier field corresponding to the execution logic element "from which to query", "primary_table" and "products" are the target metadata fields corresponding to the execution logic element "product data table".

[0066] By leveraging a language model to process multiple structured data points represented by domain-specific language format attributes in this example, corresponding query statements can be generated. This allows for a more accurate representation of the dependencies between identifiers and metadata fields in the query statement using multiple intermediate structured data points, thereby improving the efficiency and accuracy of query generation and enhancing business response efficiency.

[0067] In some embodiments, intent recognition is performed on the requirement text to obtain the requirement intent, including: using a language model to recognize the intent of the requirement text to obtain structured requirement content.

[0068] According to embodiments of this application, the demand intent includes structured demand content, which includes data attribute items and data content related to metadata in the query statement. Data attribute items represent the attribute types of metadata fields, and data content represents the metadata fields based on text. For example, demand attribute items might be "Region," "Time Range," and "Indicator Type," with associated data content such as "Region A," "2024," and "Return Rate." By representing demand intent based on associated data attribute items and data content within structured demand content, the semantic model can more accurately understand the demand semantics represented by the demand text and accurately transform the demand semantics into intermediate structured data that represents the target task in the query statement, thereby improving the accuracy of the query statement and the degree of matching between the query statement and the demand semantics of the demand text.

[0069] In one embodiment, the requirement intent may include the following structured requirement content.

[0070] basic_type: “Comparative”. complexity: “Medium”. normalized_question: “Compare the differences in mobile phone return rates between [Region A, Region B] in [First Half of 2024] and [Second Half of 2024]”. keywords: “Mobile phone”, “Return rate”. dimensions: Region: [“Region A”, “Region B”]. Time base period: label: “First Half”. Time comparison period: label: “Second Half”.

[0071] In some embodiments, performing intent recognition on the requirement text to obtain the requirement intent further includes: using a language model to semantically update the requirement text to obtain the target requirement text.

[0072] According to an embodiment of this application, the target requirement text represents at least one requirement content based on a specified tag, and the target requirement text is used to perform semantic understanding of the requirement intent based on the associated specified tag and requirement content prompting language model.

[0073] For example, if the demand text is "Compare the mobile phone return rates of Region A and Region B (Eastern Region) in the first and second halves of 2024", the updated target demand text output by the language model is: "Compare the differences in [mobile phone return rates] between [the first half of 2024] and [the second half of 2024] for [Region A (Eastern Region) and Region B (Eastern Region)". Here, "[]" represents associated specification markers. These markers, by enclosing the demand content, prompt the language model to accurately identify the actual demand intent represented by the demand text. This allows the language model to accurately understand the semantics of the target demand text within the demand intent, outputting a query statement that accurately describes the execution logic elements and structured relationships of the target task. This improves the accuracy of intermediate structured data and the accuracy of the query statement, reducing the possibility of the language model outputting query statements unrelated to the business database due to semantic illusion, thus improving the quality of the query statement.

[0074] In some embodiments, the demand intent also includes the demand complexity determined through semantic understanding of the demand text using a language model. Demand complexity represents the complexity of executing a query statement. For example, demand complexity can represent the complexity of the query statement's execution conditions, operational complexity, or the complexity of data attribute items in metadata.

[0075] For example, requirement complexity can be represented by the number of data attribute items in the requirement content. The more data attribute items there are, the more different types of metadata dimensions the query statement needs to perform operations on. It can be understood that the more data attribute items there are, the higher the requirement complexity.

[0076] In one embodiment, the complexity of the requirement text can be scored based on multiple dimensions, and the requirement complexity score is determined according to the complexity scores corresponding to the multiple dimensions. The requirement complexity score Qcs = Ds + Os + Cs + Ms can be understood as requirement complexity = data attribute item score + operation complexity score + condition complexity score + correction score.

[0077] The data attribute score Ds represents the number of dimensions of specific data attribute items explicitly mentioned in the requirement text. For example, if the requirement text includes three different data attribute items—region, time, and product—one point is added for each additional data attribute item, with a maximum score of 3 points for Ds. The operation complexity score Os ranges from 0 to 4, representing the level of operational complexity implicit in the requirement text. For instance, the content shown in Table 1 can be used as a prompt, and the prompt language model can output the operation complexity score by processing the requirement text.

[0078] Table 1

[0079]

[0080] The condition complexity score Cs ranges from 0 to 3, representing the complexity of the filtering conditions in the query statement represented by the requirement text. For example, the content shown in Table 2 can be used as a prompt to guide the language model in processing the requirement text and outputting the condition complexity score.

[0081] Table 2

[0082]

[0083] The correction score Ms is used to correct the requirement complexity score. It can be set based on experience or determined by calibrating and adjusting based on historical execution results.

[0084] In one embodiment, requirement complexity can also be represented based on a complexity level type. For example, a preset complexity rating scale can be queried based on a requirement complexity score. In the preset complexity rating scale, a requirement complexity score of 0-3 represents a simple level, a requirement complexity score of 4-7 represents a medium level, and a requirement complexity score of 8-10 represents a complex level. The requirement complexity is represented by the complexity level type.

[0085] In some embodiments, requirement complexity is used to prompt the language model, and the requirement intent is processed based on the thought process topology that matches the requirement complexity to obtain the execution logic structure.

[0086] According to embodiments of this application, the thought process topology can represent the thought tasks that a language model needs to perform during the thought process of processing a demand intent. A thought process topology matching the demand complexity can represent the depth of thought in the thought process that matches the complexity level or complexity score of the demand complexity. By performing processing tasks for the demand intent based on the depth of thought matching the demand complexity, the language model can be prompted to avoid overthinking demand intents with low complexity and to avoid insufficient depth of thought for demand intents with high complexity by using demand complexity as a prompt. This improves the matching degree between the execution logic structure and the execution process required by the query statement representing the demand intent, thereby improving the accuracy of the intermediate structured data in describing the execution process of multiple target tasks in the query statement, and ultimately improving the accuracy of the generated query statement.

[0087] In some embodiments, the topological complexity of the thinking process topology can represent the depth of thinking in the thinking process. Alternatively, the depth of thinking can also be represented by the number of thinking tasks in the thinking process topology.

[0088] Figure 3 A schematic diagram of the thought process topology according to an embodiment of this application is shown.

[0089] like Figure 3 As shown, the thinking process topology 300 includes multiple thinking tasks. These tasks are represented by circular nodes. The first thinking task determines a storage area, specifically identifying a storage area matching the desired intent from a preset storage area as the execution area for the query statement. The second thinking task determines the table name field corresponding to the desired intent "Area A" and uses it as the target metadata field. The third thinking task determines the specific time condition field "January 1, 2020 to June 30, 2020" based on the desired intent "First half of 2020". The fourth thinking task performs a function field transformation on the desired intent "summation" to obtain the function editing process task.

[0090] According to embodiments of this application, processing the requirement intent using a language model to obtain the execution logic structure may include: determining the topology of the thinking process by performing task planning on the requirement content in the requirement intent based on the requirement complexity; and executing multiple thinking tasks based on dependencies using the language model to output the execution logic structure.

[0091] In some embodiments, multiple thinking tasks in the thinking process topology are dependent on each other, and the number of thinking tasks matches the complexity of the requirements.

[0092] For example, if the complexity score in the demand intent is 3, the language model can use this complexity as a prompt to plan tasks for multiple related data attributes and data content in the demand intent, thus outputting a thought process topology. The number of thinking tasks in the thought process topology matches the number of preset tasks corresponding to a complexity score of 3.

[0093] For example, if the complexity level of a requirement in a requirement intent is "medium," the language model can use this complexity level as a prompt to plan tasks for multiple related data attributes and data content within the requirement intent, thereby outputting a thought process topology. The number of thinking tasks in the thought process topology matches the number of preset tasks corresponding to the complexity level of "medium."

[0094] According to embodiments of this application, intent recognition is performed on the requirement text to determine the requirement complexity and content. Based on the requirement complexity, the language model is prompted to plan tasks according to the complexity of multiple target tasks in the query statement represented by the requirement text, thereby avoiding overthinking or underthinking of the requirement intent. Thus, by using the requirement complexity prompt, the language model can be controlled to generate a thought process topology that matches the requirement complexity. This achieves explicit control over the language model to prevent it from generating illusions that lead to a mismatch between the semantics of the text representing the execution logic structure, the execution process, and the execution process and target tasks of the query statement, thereby improving the accuracy of query statement generation.

[0095] In one embodiment, the number of thinking tasks in the thinking process topology matches the complexity of the requirements. Each thinking task is associated with an execution logic element that shares the same attributes. For example, a time-range thinking task in the thinking process topology is used to process the requirement content "Time: the last three fiscal years" and "Industry: professional sports league management teams" through an instruction language model, outputting the time attribute element "September 1, 2020 to September 1, 2023" related to the time attribute. Thus, by using thinking tasks associated with multiple attributes in the thinking process topology, multiple execution logic elements corresponding to each attribute can be output. This allows for a more precise representation of metadata fields such as conditional content and table names related to the target task of the query statement through the more accurate text content of the execution logic elements. This improves the accuracy of the execution logic structure in representing the execution process of the query statement, further enhancing the efficiency and accuracy of query statement generation and improving business response efficiency.

[0096] In some embodiments, the requirement intent to satisfy a preset requirement condition includes: the requirement complexity is greater than or equal to a preset complexity threshold. For example, the requirement complexity score in the requirement intent is greater than or equal to a preset complexity score threshold, or, for another example, the requirement complexity level in the requirement intent may be greater than a preset level type.

[0097] In one example, when the requirement complexity is greater than or equal to a preset complexity threshold, a language model is used to process the requirement intent and output the execution logic structure. Intermediate structured data is then generated based on the execution logic structure and target pattern information, and a query statement is generated from this intermediate structured data. When the requirement complexity is less than the preset complexity threshold, it can be determined that the requirement intent does not meet the preset requirement conditions. Therefore, a language model can be used to process simpler requirement intents and directly output query statements, thereby improving the efficiency of query statement generation for requirement texts with relatively simple semantics. This enhances the adaptability and flexibility of the query statement generation method provided in this application embodiment for different requirement texts.

[0098] In some embodiments, the execution logic element includes at least one of the following: a time attribute element representing time conditions; a region attribute element representing region conditions; and an indicator type element representing the calculated indicator in the demand intent.

[0099] According to embodiments of this application, the time attribute element is text related to the time field in a preset metadata field. For example, the time attribute element is text that can accurately represent the semantics of time, such as "first half of 2024" or "first quarter of 2020".

[0100] The regional attribute element is text related to the regional scope in the preset metadata field. For example, the regional attribute element is text such as "Region A" or "Urban Area of ​​Region A", which can accurately represent the semantics of the regional attribute.

[0101] The indicator type element represents the metadata fields related to the indicator type in the preset metadata fields. For example, the indicator type element represents the text of the table name and column name fields related to the profit margin indicator type.

[0102] Figure 4 A schematic diagram of the execution logic structure according to an embodiment of this application is shown.

[0103] like Figure 4 As shown, the execution logic structure 400 includes multiple substructures, including an entity element structure 410 and a time attribute element structure 420. The entity element structure 410 includes a first-level execution logic element, "Entity Element Definition," and second-level execution logic elements, "Mobile Phone," "Area A," and "Area B." The dotted lines between these execution logic elements indicate their structured relationships. The first-level execution logic element can semantically indicate that the multiple execution logic elements in the entity element structure 410 are metadata fields related to data tables, indexes, and other objects in the database that the language model needs to focus on.

[0104] The time attribute element structure 420 includes the first-level execution logic element "Time Attribute Description", the second-level execution logic element "Time Period Comparison", and the third-level execution logic elements "Baseline Time Period: Tag: First Half of 2024; Time Period Range: 2024-01-01 to 2024-06-30" and "Target Time Period: Tag: Second Half of 2024; Time Period Range: 2024-07-01 to 2024-12-31". The "Time Attribute Description" can use textual semantics to instruct the language model to understand and generate target tasks related to time conditions. "Time Period Comparison" can prompt the language model to understand the specific task condition of the target task as "comparing data from different time periods". The third-level execution logic element can represent the time boundaries of the specific task conditions in "comparing data from different time periods" based on structured relationships. This allows the time attribute element structure 420 to accurately determine the time attribute conditions of the target task through the language model, and to construct metadata fields such as table fields and column fields that match the time attribute conditions by combining the semantics of other execution logic elements. This enables the intermediate structured data to more accurately represent the execution process of multiple target tasks in the query statement, thereby improving the accuracy of the generated query statement and avoiding the language model from producing illusions.

[0105] In one example, the user inputs the demand text "Compare the mobile phone return rates in regions A and B in the first and second halves of 2024". By performing intent recognition on the demand text, the demand intent is obtained; and by using a language model to semantically understand the demand intent, the output execution logic structure can be represented based on the following content enclosed in "#", where the content in "()" represents the explanation of the function or role of the execution logic element.

[0106] #operation: COMPARISON (indicates that the query statement required by the request text is of the type of comparison)#.

[0107] Entity element definition (first-level execution logic element). product: attributes: [category] (attribute: type); filters: ["category = 'mobile phone'"] (indicates the execution logic element for business type constraints) #.

[0108] #region: attributes: [name]; filters: ["name IN ('Region A','Region B')"] (Indicates region attribute filtering conditions). metric:type: RATE (Indicates metric type is ratio). name: "return_rate" (Indicates metric type is return rate). calculation: "returned_quantity / total_quantity" (Indicates the logical calculation method of "return rate" is: total returned quantity / total sold quantity)#.

[0109] #Time attribute description. temporal: (indicates the time attribute); comparison_type: PERIOD_COMPARISON (indicates the period comparison); base__period: (indicates the base period); label: "First half of 2024"; range: "2024-01-01 to 2024-06-30" (indicates the boundary of the time attribute condition); aggregation:REQUIRED (indicates that aggregation calculation is required); target_period: (indicates the target period); label: "Second half of 2024"; range: "2024-07-01 to 2024-12-31" (indicates the specific target period boundary); aggregation:REQUIRED (indicates that aggregation calculation is required)#.

[0110] #Logical analysis structure; dimensions: (indicates logical analysis dimensions); entity: region (entity: region); attribute: name (attribute: name); role: GROUP_KEY (indicates the basis for "grouping" in the query statement); values: ["A region", "B region"] (indicates the value fields that "grouping" should be based on)#.

[0111] #Logical calculation structure, Projections, type: DIMENSION, source: region.name, alias: "region", type: METRIC, source: metric.return_rate (indicates the metric type), alias: "first half return rate", context: base_period; (indicates that the first half return rate is bound to data related to the base period), type: METRIC, source: metric.return_rate, alias: "second half return rate", context: target_period; (indicates that the second half return rate is bound to data related to the target period)#.

[0112] Calculate feature description; characteristics: aggregation_level: - region- time_period Aggregate by region + period#.

[0113] It should be noted that the text paragraph relationships or text syntax structure relationships between different execution logic element lines in this example can represent the structured relationships between execution logic elements. Strings separated by commas, semicolons, and periods can also be understood as a single execution logic element.

[0114] According to the embodiments of this application, the text semantics represented by each of the multiple execution logic elements in the execution logic structure, as well as the structured relationships between the multiple execution logic elements based on the text syntax structure type, can clearly indicate to the language model with strong natural language understanding capabilities that by performing text semantic understanding on the execution logic elements and structured relationships of the execution logic structure, it can output multiple intermediate structured data that can accurately describe multiple target tasks that match the required text, thereby improving the accuracy of the query statement and avoiding errors in the understanding of target tasks or the output of logical execution relationships between multiple target tasks due to unclear semantic understanding by the language model.

[0115] In some embodiments, determining the target schema information that matches the text semantics represented by the execution logic element from the preset database schema information may include: performing semantic matching between the execution logic element and the preset database schema information to obtain multiple candidate metadata fields related to the execution logic element; and determining the target metadata field that matches the execution logic element from the multiple candidate metadata fields based on the intent semantic matching result between the candidate metadata fields and the demand intent.

[0116] According to embodiments of this application, candidate metadata fields represent database objects in preset database schema information. For example, candidate metadata fields may represent database objects such as tables and columns in the preset database schema information.

[0117] In some embodiments, semantic matching based on execution logic elements and preset database pattern information may include calculating the semantic similarity between execution logic elements and preset metadata fields in preset database pattern information based on similarity algorithms and neural network algorithms, and determining preset metadata fields that meet the similarity threshold as candidate metadata fields.

[0118] According to embodiments of this application, the intent semantic matching result between the candidate metadata field and the requirement intent may include the intent semantic matching result between the candidate metadata field and one or more requirement contents in the requirement intent. Alternatively, the intent semantic matching result may also include the semantic matching result between the candidate metadata field and the updated target requirement text in the requirement intent.

[0119] In some examples, based on the intent semantic matching results between candidate metadata fields and the demand intent, a target metadata field matching the execution logic element is determined from multiple candidate metadata fields. This can include assigning corresponding semantic matching weights to multiple candidate metadata fields based on the intent semantic matching results, and determining the target metadata field matching the textual semantics of the execution logic element based on the semantic matching weights. By determining the target metadata field matching the execution logic element and inputting the target metadata field and the execution logic structure into the language model, the language model is prompted to understand the mapping relationship between the textual semantics of the execution logic element and the target metadata field. This avoids misinterpretations that could lead to incorrect output of metadata fields such as table name fields and column name fields in the output query statement, thereby improving the accuracy of query data generation by outputting precise intermediate structured data.

[0120] In some embodiments, multiple preset metadata fields in the preset database schema information can be traversed, and relevance ranking can be performed based on the semantic similarity between each preset metadata field and the execution logic element to obtain candidate metadata fields whose ranking positions meet preset position conditions. Then, the candidate metadata fields are re-ranked based on the semantic matching result between the demand intent and the candidate metadata fields to obtain the target metadata fields whose ranking positions meet the conditions.

[0121] In some embodiments, determining the target metadata field that matches the execution logic element from multiple candidate metadata fields based on the intent semantic matching result between the candidate metadata fields and the demand intent may include: for any target execution logic element among the multiple execution logic elements, determining the matching weight of each of the multiple candidate metadata fields based on the intent semantic matching result corresponding to each of the multiple candidate metadata fields related to the target execution logic element; determining the field matching result between the first target metadata field that matches other execution logic elements and the candidate metadata fields; updating the matching weight of each of the multiple candidate metadata fields based on the field matching result to obtain the target matching weight of each of the multiple candidate metadata fields; and determining the second target metadata field that matches the target execution logic element from multiple candidate metadata fields based on the multiple target matching weights.

[0122] According to embodiments of this application, the other execution logic elements are execution logic elements different from the target execution logic element, and the first target metadata field is the currently generated target metadata field, which matches the other execution logic elements. The specific process of determining the second target metadata field will be described below in conjunction with Embodiments 1 and 2.

[0123] In Example 1, in the first stage, the target execution logic element is "sales amount". The multiple candidate metadata fields that match "sales amount" are "orders.amount" (representing the order table, where the data is related to the original order amount), "transactions.total" (representing the payment table, where the data is related to the actual payment amount), and "invoices.value" (representing the invoice table, where the data is related to the invoice amount).

[0124] In the second stage, by semantically matching “orders.amount”, “transactions.total”, and “invoices.value” with the demand content [orders, departments, region A] in the demand intent, the matching weights of the candidate metadata fields were 0.6, 0.3, and 0.2, respectively. This confirms that the user's demand intent points to data related to the “orders table”.

[0125] In the third stage, the first target metadata field "orders.region_id" is used to find the other execution logic element "Region A" that matches it semantically against multiple candidate fields. This yields multiple field similarities as the matching results. Based on these similarities, the target matching weights for "orders.amount", "transactions.total", and "invoices.value" are updated to 0.9, 0.07, and 0.03 respectively. Therefore, if "orders.region_id" matches another execution logic element "Region A" and indicates the foreign key table field "orders", then "orders.amount" can be used as the second target metadata field to match the target execution logic element.

[0126] The difference between Example 2 and Example 1 is that the demand intent is "unpaid". Therefore, the target execution logic element "sales amount" is matched with "orders.amount", "transactions.total", and "invoices.value", with matching weights of 0.3, 0.6, and 0.2 respectively. When the first target metadata field matching other execution logic elements is "transactions.region", the target matching weights for "orders.amount", "transactions.total", and "invoices.value" are determined to be 0.09, 0.9, and 0.01 respectively. Therefore, "transactions.total" is determined to be the second target metadata field.

[0127] According to embodiments of this application, the target schema information includes a target metadata field corresponding to an execution logic element. The execution logic element can be text-based representations of metadata to be processed in the target task, and the target metadata field is a metadata field determined from preset database schema information that matches the execution logic element. For example, if the execution logic element is "sales amount," the target metadata field matching "sales amount" is "order.amount."

[0128] In some embodiments, using a language model to semantically understand multiple execution logic elements and target pattern information, outputting multiple intermediate structured data to describe a query statement may include: processing multiple execution logic elements using a language model based on target metadata fields as prompt information, outputting associated identifiers and target metadata fields; and determining intermediate structured data based on the associated identifiers and target metadata fields.

[0129] According to embodiments of this application, the identifier can represent various query statement keywords in the query statement, such as "FROM", "JOIN", "WHERE", "GROUP", etc. The target metadata field associated with the identifier can be the metadata field corresponding to the keyword in the preset database schema information. For example, the target metadata field can be the table name field corresponding to "FROM", the column name field corresponding to "WHERE", etc.

[0130] In some embodiments, the intermediate structured data may also include associated function fields and target metadata fields, thereby enabling the intermediate structured data to accurately represent the computational tasks to be performed in the query statement, thus improving the accuracy of the query statement.

[0131] In some embodiments, matching execution logic elements and target metadata fields can prompt the language model to generate multiple target tasks related to the identifier in the query statement based on the execution logic relationships of multiple target tasks indicated by the execution logic structure. Thus, by filling the target metadata fields into target task strings of various types that match the execution logic structure, precise binding of the identifier and target metadata fields according to the textual semantics of the execution logic structure is achieved, avoiding errors in the expression of the query statement in the intermediate structured data.

[0132] For example, if the objective task is to "find the corresponding table", the language model can be instructed to associate the identifier "FROM" with the table name field to form intermediate structured data based on the hint that the table name field matches the execution logic element "sales amount".

[0133] For example, if the objective task is to "find the corresponding column", the language model can be instructed to bind the identifier SELECT with the column name field in the list and the column name field in the WHERE condition based on the hint of the column name field that matches the execution logic element "return order".

[0134] For example, if the target task is "specify join conditions and columns", the language model can be instructed to bind the table name fields and column name fields corresponding to JOIN and ON respectively, based on the hints of the table fields and column name fields that match the execution logic element "return order".

[0135] For example, if the objective task is to "indicate the range of values ​​for metadata", the language model can be instructed to bind the identifier WHERE column to the attribute value field [VALUE] based on the attribute value threshold hint that matches the execution logic element "return rate".

[0136] In one embodiment, the demand text is: "Products in region A or region B within the mobile phone category with a rating below 3 stars or a return rate exceeding 10%." Multiple intermediate structured data can be represented as content enclosed in "#".

[0137] #{"operation": "SELECT". "columns": [{"name": "product_name", "alias":"product name"}, {"name": "region", "alias": "region"}, {"name": "avg_rating", "alias": "average rating"}, {"name": "return_rate", "alias": "return rate"}]#.

[0138] #"from": {"primary_table": "products","joins": [{"type": "INNERJOIN", "table": "sales_stats", "on": "products.id = sales_stats.product_id"},{"type": "INNER JOIN", "table": "regions", "on": "sales_stats.region_id =regions.id"}]}#.

[0139] #"where": ["(regions.name IN ('A region', 'B region'))","products.category= 'mobile phone'","(sales_stats.avg_rating < 3 OR sales_stats.return_rate > 0.1)"]}#.

[0140] In this embodiment, each segment can be understood as an intermediate structured data, and the paragraph relationships between multiple intermediate structured data can represent the dependencies between them. The intermediate structured data can be nested to represent the binding relationships between multiple identifiers and target metadata. For example, in "where":["(regions.name IN ('A region')", "regions.name" and "A region" can be target metadata fields bound to the identifier "where", and "A region" is a target metadata field bound to the identifier "IN".

[0141] According to embodiments of this application, by using target metadata as a prompt and leveraging a language model to process multiple execution logic elements and structured relationships within the execution logic structure, the language model can accurately bind identifiers related to target tasks and target metadata fields while clearly understanding the task attributes and execution logic of multiple target tasks in the query data. For example, it can ensure that identifiers such as SELECT projection items, FROM table, JOIN conditions, and WHERE conditions are correctly bound to corresponding table fields, index fields, and other target metadata fields. This allows intermediate structured data to represent the task attributes of the target tasks while precisely binding database schema information and execution logic elements. Furthermore, by filling target metadata fields, it generates intermediate structured data that accurately represents the target tasks, significantly reducing cross-table query field confusion and condition loss that occur when converting natural language to query statements. It also avoids the "black box" illusion of language models, such as confusion of fields with the same name in query statements, the appearance of fictitious metadata fields, and semantic understanding biases. By using a language model to generate complete, detailed, and verifiable intermediate structured data to describe query statements, this mechanism "fills in" multiple target tasks represented by the execution logic structure using target metadata fields. This avoids execution errors in query statements caused by mismatches in table name fields, attribute value fields, etc., thereby improving the accuracy of query statements. This achieves a high-precision, interpretable, and self-correcting conversion mechanism from natural language to query statements, suitable for applications such as business intelligence, finance, and healthcare where stringent accuracy requirements for query statements are essential.

[0142] In some embodiments, the language model outputs intermediate structured data by performing the following operations: semantically understanding the task type element representing the target task type to obtain an identifier that matches the target task type; semantically transforming the task entity element representing the target metadata to determine the target metadata field corresponding to the task entity element; and determining the associated identifier and target metadata field based on the structured relationship between the task type element and the task entity element.

[0143] According to embodiments of this application, the task type element representing multiple types of target tasks can be based on text representing function fields such as "SUM", or it can also be based on text content representing condition keyword fields such as "WHERE". The task entity element can be text such as "sales amount" related to the table name field "order.amount".

[0144] In one embodiment, multiple intermediate structured data corresponding to the requirement text "Compare the mobile phone return rates in Region A and Region B in the first and second halves of 2024" can be represented based on the content enclosed by "#".

[0145] #{"operation": "SELECT","columns": [{"expression": "region_dim.region_name","alias": "Region","type": "DIMENSION","source_logical": "region.name"}#。

[0146] #{"expression": "SUM(returns_fact.returned_quantity) FILTER (WHEREreturns_fact.sale_ date BETWEEN '2024-01-01' AND '2024-06-30') / NULLIF(UM(returns_fact.total_quantity)) FILTER (WHERE returns_fact.sale_date BETWEEN '2024-01-01' AND '2024-06-30'), 0)","alias": "(Return Rate in the First Half of the Year)"," type": "METRIC","source_ logical": " metric.return_rate","context": "base_ period"}#。

[0147] #{" expression": "SUM(returns_fact.returned_quantity) FILTER (WHEREreturns_fact.sale_date BETWEEN '2024-07-01' AND '2024-12-31') / NULLIF(SUM(eturns_fact.total_quantity) FILTER (WHERE returns_fact.sale_date BETWEEN '2024-07-01' AND '2024-12-31'), 0)","al)": "Return Rate in the Second Half of the Year","type": "METRIC","source_logical": "metric.return_rate","context": "target_period"}]#。

[0148] It should be noted that there seems to be a typo in the original text in line where "SUM(eturns_fact.total_quantity)" has an extra 'e' in "eturns_fact". This has been left as is in the translation for the purpose of following the original text exactly.#"from": {"primary_table": "returns_fact","joins": [{"type": "INNERJOIN","table": "product_dim","on": "returns_fact.product_id = product_dim.product_id","purpose": (Indicates the product filtering conditions to be applied)}#.

[0149] #{"type": "INNER JOIN","table": "region_dim","on": "returns_fact.region_id = region_dim.region_id","purpose": (indicates applying region grouping and filtering)}]}#.

[0150] #"where": ["product_dim.category = 'mobile phone'","region_dim.region_name IN('A region', 'B region')","returns_fact.sale_date BETWEEN '2024-01-01' AND '2024-12-31'"],"group_by": ["region_dim.region_name"]#.

[0151] #"having": [], "order_by": [], "metadata": {"comparison_type": "PERIOD_COMPARISON"," aggregation_level": ["region", "time_period"]; "consistency_checks": {" projection_columns_in_group_by": "PASS (indicates that the grouping column (region_dim.region_name) is in the projection)"; "where_columns_in_joins": "PASS (indicates that all WHERE condition reference columns (product_dim.category, region_dim.region_name, returns_fact.sale_date) are from the FROM / JOIN table"; " data_type_validation": {" product_dim.category": "STRING - Matching value type 'mobile'","region_dim.region_name": "STRING - Matching value list ('region A', 'region B')"; " "returns_fact.sale_date": "DATE ​​(represents a matching date range)"

[0152] In this embodiment, paragraphs based on intermediate structured data can represent the structured relationships between intermediate structured data. The intermediate structured data can preserve the textual semantics of execution logic elements and the execution logic relationships between multiple target tasks, thereby ensuring the correct binding relationship between metadata fields and identifiers. This enables mapping execution logic elements based on intermediate structured data to ensure consistency between query statements and user intent. Furthermore, relevant personnel can edit and generate updated intermediate structured data. Therefore, by performing semantic transformation on the intermediate structured data, highly accurate query data can be obtained.

[0153] For example, a query statement enclosed in "#" can be generated based on multiple intermediate structured data in this embodiment.

[0154] #SELECT.

[0155] region_dim.region_name AS "region"#.

[0156] #SUM(returns_fact.returned_quantity) FILTER (WHERE returns_fact.sale_date BETWEEN '2024-01-01' AND '2024-06-30') / NULLIF(SUM(returns_fact.total_quantity) FILTER (WHERE returns_fact.sale_date BETWEEN '2024-01-01' AND '2024-06-30'), 0) AS "Return rate in the first half of the year"#.

[0157] #SUM(returns_fact.returned_ quantity) FILTER (WHERE returns_fact.sale_date BETWEEN '2024-07-01' AND '2024-12-31') / NULLIF(SUM(returns_fact.total_quantity) FILTER (WHERE returns_fact.sale_date BETWEEN '2024-07-01' AND '2024-12-31'), 0) AS "Return rate in the second half of the year"#.

[0158] #FROM returns_fact. INNER JOIN product_dim ON returns_fact.region_id =product_dim.product_id. INNER JOIN region_dim ON returns_fact.region_id =region_dim.region_id. WHERE product_dim. dim.category='Mobile phone. 'AND region_dim.region_name IN ('A region', 'B region'). AND returns_fact.sale_date BETWEEN '2024-01-01' AND '2024-12-31'GROUP BY region_dim.region_name#.

[0159] It should be noted that, in the intermediate structured data, execution logic structure, and query statements of this application embodiment, two different strings separated by "," ";", and "." in the same paragraph can be understood as strings from different paragraphs in the structured information.

[0160] According to embodiments of this application, intermediate structured data is determined based on associated identifiers and target metadata fields. The language model can semantically understand task type elements and task entity elements by using the execution process of multiple target tasks represented by the execution logic structure, and the target metadata fields matching the execution logic elements as hints. This allows for refined matching of identifiers and target metadata fields, and outputs associated identifiers and target metadata fields based on the structured relationships represented by the execution logic structure as text grammatical structure relationships. This enables intermediate structured data to accurately represent the grammatical structure of the query statement and the execution process of the target task through associated identifiers and target metadata fields, improving the accuracy of the query statement.

[0161] In some embodiments, the query statement generation method further includes: performing a consistency check on the target metadata field in the intermediate structured data based on the preset metadata field in the preset database schema information to obtain a consistency check result; and checking the attribute information in the intermediate structured data corresponding to the target metadata field to obtain an attribute compliance check result.

[0162] In some embodiments, the consistency check result obtained by performing a consistency check on the target metadata field can indicate whether the target metadata field exists in the preset database schema information. This checks whether the identifiers bound in the intermediate structured data and the target metadata field conform to the execution logic of the target task. For example, the consistency check result indicates that the columns referenced in the WHERE condition must come from the table in the FROM / JOIN. Another example is that the consistency check result indicates that the grouping columns must be in the projection or aggregate function.

[0163] In some embodiments, the attribute compliance verification result indicates whether the attribute value range, attribute value type, and other attribute information corresponding to the target metadata field match the preset attribute information set by the preset database mode.

[0164] According to embodiments of this application, the defect information represented by the consistency check result and the attribute compliance check result is used to prompt the language model to update the current intermediate structured data, thereby obtaining updated intermediate structured data. Thus, the check results can be used to prompt the language model to automatically correct whether object fields such as tables, columns, and indexes are identical to the target metadata fields based on the defects indicated by the check results. This quickly corrects field errors in the language model's output and improves the accuracy of the intermediate structured data.

[0165] In one embodiment, various types of checks can be performed on the intermediate structured data, such as entity binding check, attribute binding check, connection path binding check, value binding and type check, function / operator specification check, alias management check, integrity check, and consistency check. If all the check results pass, the data is determined to be used to generate query statements from multiple intermediate structured data.

[0166] Entity binding validation means determining whether the business entity text (such as "product" or "sales amount") in the intermediate structured data and execution logic elements is mapped to specific database table fields.

[0167] Attribute binding validation means mapping the text of keywords such as representation, projection, condition, grouping, sorting, and connection keys in the execution logic element to specific table columns, thereby resolving text ambiguity that could lead to mapping to multiple tables or column fields.

[0168] Join path binding validation means: for join types such as INNER / LEFT, it validates the specific tables involved in the specified join and the specific columns used in the join. It requires using information such as foreign key relationships to deduce or validate the join path.

[0169] Value binding and type validation means binding the constant value (such as the specific threshold of 10000 corresponding to "high") in the condition string to the expression, and validating whether the value type is compatible with the data type of the bound column. In addition, it is also necessary to verify that the comparison object of the numeric column cannot be a string.

[0170] Function / operator specification verification: Confirm whether the specific use of aggregate functions, comparison operators, etc., is consistent with the column data type (e.g., SUM() can only be used on numeric columns).

[0171] Alias ​​Management Validation: Verifies that the aliases of data tables or complex expressions are the same as the aliases in the preset database schema information.

[0172] In some embodiments, the query data generation method may further include: in response to the requirement complexity being less than a preset complexity threshold, determining intent pattern information from preset database pattern information that matches the text semantics of the requirement intent representation; and using a language model to perform semantic understanding of the requirement intent and intent pattern information, outputting multiple intermediate structured intent data for describing the query statement, and generating a reference query statement based on the multiple intermediate structured intent data.

[0173] According to embodiments of this application, determining intent pattern information that matches the semantics of the text representing the demand intent from preset database pattern information may include semantically matching the preset database pattern information with multiple demand intents respectively, obtaining the semantically matched intent pattern information for each of the multiple demand intents. This establishes a binding relationship between the preset database pattern information and the demand intents. By utilizing a language model to process the matched intent pattern information and demand intents, intermediate structured intent data that accurately represents the execution logic of the target task can be output. This allows for the generation of reference query statements with low demand text complexity based on multiple intermediate structured intent data.

[0174] According to the embodiments of this application, when the complexity of the requirement is less than a preset complexity threshold, the intent pattern information that matches the text of the requirement intent can be directly determined to prompt the language model to generate intermediate structured data of the intent. This can reduce the computation time delay caused by generating query statements for requirement text with low complexity and improve the efficiency of query statement generation.

[0175] In some embodiments, the intent schema information includes intent metadata fields that match the demand intent. The intent metadata fields may represent objects such as tables and columns in a preset database schema that match the text content of the demand intent.

[0176] In some embodiments, using a language model to perform semantic understanding of demand intent and intent pattern information, and outputting multiple intermediate structured data of intent to describe the query statement may include: using the language model to perform semantic understanding of demand intent and intent metadata fields to obtain associated intent identifiers and intent metadata fields; and determining intermediate structured data of intent based on the associated intent identifiers and intent metadata fields.

[0177] According to embodiments of this application, an intent identifier can represent an identifier that matches the textual semantics of a demand intent. By prompting a language model to semantically understand the matched demand intent based on intent pattern information, the textual semantics related to the task type of the target task in the demand intent can be converted into an intent identifier. A binding relationship is established between the intent metadata field matching the demand intent and the intent identifier to determine the associated intent identifier and intent metadata field. Thus, the language model can generate intermediate structured intent data by processing the associated intent identifier and intent metadata field. This ensures that the binding relationship between the intent metadata field and the intent identifier in the intermediate structured intent data matches the demand intent and accurately represents the syntactic and query logic relationships between identifiers such as "WHERE" in the target task of the query statement and table / column fields, thereby improving the accuracy of the query statement.

[0178] In some embodiments, the query statement generation method may further include: verifying multiple execution logic elements in the execution logic structure based on business data attributes in business rules related to the demand text, and obtaining semantic verification results; and verifying the dependency relationships between multiple execution logic elements based on the accounting rules in the business rules, and obtaining accounting logic verification results.

[0179] According to embodiments of this application, the semantic verification result characterizes the semantic consistency between the execution logic element and the business data attribute. For example, the execution logic element is "Product AA", which has semantic consistency with the product name attribute "Product AA" in the business data. By using a language model to semantically understand the demand intent based on the metadata fields corresponding to the product name attribute in the preset database schema information, the execution logic element that accurately matches the product name attribute can be output.

[0180] For example, the execution logic element "A Region" is semantically inconsistent with the region name attribute "City A, Region A" in the business data. The semantic differences between the execution logic element and the business attribute can be represented based on the semantic validation results.

[0181] According to embodiments of this application, the accounting logic verification result characterizes whether the structured relationship satisfies the accounting execution logic characterized by the accounting rules. For example, the accounting logic verification result can characterize whether the calculation logic process for calculating the company's profit margin, represented by the structured relationship, matches the accounting process indicated by the business rules. If the semantic verification result and the accounting logic verification result indicate correct verification, the structured relationship and execution logic elements corresponding to the accounting logic verification result, as well as the target pattern information, can be input into the language pattern information to generate accurate intermediate structured data.

[0182] In some embodiments, the defect information represented by the semantic verification result and the accounting logic verification result is used to prompt the language model to update the current execution logic structure, resulting in an updated execution logic structure. This allows for the output of accurate intermediate structured data based on the updated execution logic structure and target pattern information from the language model.

[0183] In some embodiments, validation can be performed on the demand intent, execution logic structure, intermediate structured data, and query statements to ensure that the generated query statements can accurately and efficiently execute business services and improve the response efficiency of business services.

[0184] Figure 5 A schematic diagram of a query statement generation method according to an embodiment of this application is shown.

[0185] like Figure 5As shown, a query statement is generated based on a semantic injection module, a query statement transformation chain, and a validation chain. The semantic injection module stores and manages multimodal business data such as images, data tables, and text, as well as storing preset database schema information. The first node in the query statement transformation chain uses the semantic injection module to call business data as prompts, processes the requirement text using a language model, and outputs the requirement intent. The second node calls the language model to process the requirement intent and obtain the execution logic structure. The third node uses the semantic injection module to call the target schema information and execution logic structure, uses the language model to perform semantic understanding of the target schema information and execution logic structure, and outputs multiple intermediate structured data. The fourth node calls the language model to edit the query statement on the multiple intermediate structured data and outputs the query statement.

[0186] The validation chain consists of multiple validation nodes that validate the requirement intent, execution logic structure, intermediate structured data, and query statement output by multiple nodes in the query statement transformation chain. If the validation result does not meet the preset validation quality requirements, the defect information represented by the validation result is returned to each node so that the language model can update the requirement intent, execution logic structure, intermediate structured data, and query statement based on the defect information indicated by the validation result.

[0187] The query statement generation method provided in this application is executed through a double-chain loop structure of query statement transformation and verification links. Based on the semantic injection module, heterogeneous data semantic injection and storage of business data and preset database schema information can be performed for data processing tasks by each node in the query statement transformation link. Furthermore, multiple nodes in the query statement transformation link are matched one-to-one with multiple verification nodes in the verification link, ensuring the reliability and accuracy of query statement generation through the combination of the two links. Multiple nodes in the query statement transformation link utilize the semantic understanding capabilities of the language model and dynamic business knowledge to perform hierarchical evolution and transformation of the query statement's semantics, outputting intermediate structured data that accurately describes the query statement. Multiple verification nodes in the verification link quantitatively evaluate and verify the structured information output by the query statement transformation link to assist multiple nodes in the transformation link in optimization, and to promptly verify, correct, and optimize the information output during the query statement transformation process, thereby improving the efficiency of query statement generation and execution.

[0188] Figure 6 A structural diagram of the query statement transformation link and the verification link according to an embodiment of this application is shown.

[0189] like Figure 6As shown, the query statement transformation chain includes a first transformation layer, a second transformation layer, a third transformation layer, and a fourth transformation layer. The validation chain includes a first validation node, a second validation node, a third validation node, a fourth validation node, and a fifth validation node. Furthermore, each validation node can be associated with a corresponding inspection node. The semantic injection module can include a business background layer, a business concept layer, a business logic layer, a physical logic layer, and a data anchoring layer.

[0190] The business background layer is used to manage descriptive information such as the structure of data, business data, etc., and to provide the first transformation layer of the query data transformation chain with business data related to the specific business domain of the demand text, such as business data of retail e-commerce, supply chain finance, etc.

[0191] The second layer is the business concept layer, which explicitly defines or describes business data such as "valid orders," "active users," and "GMV." The business concept layer describes business attributes such as terms and transactions within the business domain and provides atomic indicator definitions for information such as reports and business analysis reports. Therefore, the first conversion layer can use the descriptive information from the business concept layer and the business data provided by the business background layer to understand the intent of the requirement text using a language model, and output the requirement intent that matches the business terms and concepts.

[0192] The third layer is the business logic layer, used to store business rules information such as business execution logic, business domain table partitioning, table and view definitions, and content explanations of business lines. Business rules may include, for example, rules such as "return requests must be initiated within 7 days of receipt" and "gold members enjoy free shipping," which are updated and stored in real time. Business rules may also include related business process rules, such as order fulfillment process rules and risk control approval process rules.

[0193] This allows the second conversion layer to obtain real-time business rule information from the business logic layer, enabling semantic understanding of the demand intent and outputting an execution logic structure that matches the business rules. This ensures that the structured relationship of the execution logic structure satisfies the execution logic corresponding to the business rules and that the execution logic elements are completely consistent with the specific technical terminology text in the business rules.

[0194] The fourth layer is the physical logic layer, which stores metadata information for the database tables. This metadata includes table definitions, field definitions, relationships, data types, and other related structural information. The preset database schema information for the physical logic layer is obtained by extracting information from the database schema and statistical information. Therefore, the third transformation layer can use a language model to extract target schema information from the physical logic layer that matches the execution logic elements for semantic understanding, outputting intermediate structured data.

[0195] The fifth layer is the data anchoring layer, which stores sampling point information. This information provides data support for the specific numerical data types and formats, string value binding relationships, and other sampling points in the query statement. Therefore, the fourth transformation layer can be used to call the language model to understand the sampling point information and intermediate structured data, performing the query statement transformation task and generating the query statement. The execution layer executes the query statement and outputs the results.

[0196] The semantic injection module's multiple semantic layers can provide data calling support for multiple transformation layers in the query data transformation chain, and ensure that the lower-level semantics can retain the upper-level semantic information, so that the query data transformation chain can call multi-level business data and business rules from top to bottom to achieve accurate transformation of query statements.

[0197] The first to fifth verification nodes of the verification chain can verify the structured data and query statements output by each transformation layer to ensure data quality.

[0198] The first verification node performs semantic verification on the demand intent. For example, a semantic model can be used to reverse-engineer the demand intent into natural language description text, and the semantic similarity between the original demand text and the natural language description text can be calculated. If the semantic similarity is higher than the similarity threshold of 0.92, a verification pass result is output. Alternatively, the demand intent can be combined to recall key entities in the business data. If the recall rate meets a preset recall rate threshold, a verification pass result is output. If a verification fail result is output, the demand text can be modified to re-instruct the first transformation layer to output the demand intent.

[0199] The second verification node is used to perform execution logic verification on the execution logic structure. For example, it can match the target metadata with preset database schema information, or it can verify the execution logic of the execution logic structure according to business rules, thereby verifying whether the execution logic structure conforms to business rules and metadata constraints. In addition, it can also verify the existence of entities and time compliance in the execution logic elements. If the verification result does not meet the requirements, the requirement intent can be updated, thereby prompting the second transformation layer to re-output the execution logic structure.

[0200] The third verification node is used to perform metadata binding verification on the intermediate structured data. For example, it can verify the association between identifiers and target metadata fields in the intermediate structured data, or it can include other verification types for the intermediate structured data. If the verification result indicates that the verification passed, it can instruct the fourth transformation layer to output a query statement. If the verification result fails, it can instruct the third transformation layer to regenerate new intermediate structured data based on the updated execution logic structure until the verification passes.

[0201] The fourth verification node can validate the query statement. This can be done through static syntax validation or dynamic validation based on the pre-compiled query statement. Static syntax tree validation can use tools like sqlglot to check syntax rules, while dynamic validation can generate a detailed execution plan and check for direct physical logical errors.

[0202] The fifth verification node can validate the execution results of the query statement. For example, it can assess the formal compliance of the execution results based on a preset format. Alternatively, it can set value range security boundaries based on statistical information to intercept outliers in the execution results. For instance, it can validate abnormal data such as individuals exceeding 200 years of age, the number of vehicles exceeding the local car ownership, or the number of paid members exceeding the total number of registered users. It can also perform logical consistency checks on the semantics of the execution results and the semantic logic relationship between them and the requirement text to ensure that the execution results meet the requirements of the requirement text.

[0203] Furthermore, when each verification node outputs a verification pass result, compliance checks can be performed based on their respective checkpoints, thereby further improving the accuracy and execution efficiency of the query statement.

[0204] Figure 7 A schematic diagram of a checkpoint according to an embodiment of this application is shown.

[0205] like Figure 7 As shown, a checkpoint can include an inspection component and a clarification node. The inspection component receives structured information transmitted from the transformation layer, such as receiving and inspecting the request intent, execution logic structure, intermediate structured data, and query statements. It outputs abnormal status data by detecting data with anomalies in the structured information. Abnormal status data may include metadata fields that do not match the preset database schema information. The checkpoint prompts the transformation layer to update the structured information by returning abnormal status data to the corresponding transformation layer.

[0206] In addition, users can interact with the clarification node through the human-computer interaction module to edit the structured information that contains anomalies to obtain structured information that meets the verification requirements. The edited structured information is returned to the transformation layer to continue the data processing task of the next level of the query statement transformation chain. If the structured data output by the component is normal, the data processing task of the next level of the transformation layer can continue to be executed.

[0207] Based on the above query statement generation method, this application also provides a query statement generation apparatus. The following will combine... Figure 8 The device is described in detail.

[0208] Figure 8 A structural block diagram of a query statement generation apparatus according to an embodiment of this application is shown.

[0209] like Figure 8 As shown, the query statement generation device 800 of this embodiment includes an identification module 810, an execution logic structure acquisition module 820, a target pattern information acquisition module 830, an intermediate structured data acquisition module 840, and a query statement generation module 850.

[0210] The recognition module 810 is used to perform intent recognition on the requirement text based on business data to obtain the requirement intent.

[0211] The execution logic structure acquisition module 820 is used to respond to the demand intent and meet the preset demand conditions. It uses a language model to process the demand intent and obtain the execution logic structure. The execution logic structure includes multiple execution logic elements based on structured representation. The execution logic elements represent the target task of the execution query statement or the target metadata related to the target task based on text semantics. The structured relationship between the multiple execution logic elements represents the execution process of the execution query statement.

[0212] The target pattern information acquisition module 830 is used to determine the target pattern information that matches the text semantics represented by the execution logic element from the preset database pattern information.

[0213] The intermediate structured data acquisition module 840 is used to utilize a language model to perform semantic understanding on multiple execution logic elements and target pattern information, and output multiple intermediate structured data to describe the query statement.

[0214] The query statement generation module 850 is used to generate query statements based on multiple intermediate structured data.

[0215] According to embodiments of this application, the target pattern information includes a target metadata field corresponding to the execution logic element;

[0216] According to an embodiment of this application, the intermediate structured data acquisition module includes: a first output unit and a first determination unit.

[0217] The first output unit is used to process multiple execution logic elements based on the target metadata field as prompt information, using a language model to output the associated identifier and target metadata field.

[0218] The first determining unit is used to determine intermediate structured data based on the associated identifier and target metadata fields.

[0219] According to embodiments of this application, the language model outputs intermediate structured data by performing the following operations: semantically understanding the task type element representing the target task type to obtain an identifier that matches the target task type; semantically transforming the task entity element representing the target metadata to determine the target metadata field corresponding to the task entity element; and determining the associated identifier and target metadata field based on the structured relationship between the task type element and the task entity element, wherein the intermediate structured data is determined based on the associated identifier and target metadata field.

[0220] According to an embodiment of this application, the query statement generation device further includes: a first verification module and a second verification module.

[0221] The first verification module is used to perform consistency verification on the target metadata field in the intermediate structured data based on the preset metadata field in the preset database schema information, and obtain the consistency verification result.

[0222] The second verification module is used to verify the attribute information in the intermediate structured data that corresponds to the target metadata field, and obtain the attribute compliance verification result. The defect information represented by the consistency verification result and the attribute compliance verification result is used to prompt the language model to update the current intermediate structured data, and obtain the updated intermediate structured data.

[0223] According to an embodiment of this application, the target pattern information acquisition module includes: a first acquisition unit and a second determination unit.

[0224] The first obtaining unit is used to perform semantic matching based on the execution logic element and the preset database schema information to obtain multiple candidate metadata fields related to the execution logic element, wherein the candidate metadata fields represent database objects in the preset database schema information.

[0225] The second determining unit is used to determine the target metadata field that matches the execution logic element from multiple candidate metadata fields based on the intent semantic matching result between the candidate metadata fields and the demand intent.

[0226] According to an embodiment of this application, the second determining unit includes: a first determining subunit, a second determining subunit, a first obtaining subunit, and a third determining subunit.

[0227] The first determining subunit is used to determine the matching weight of each of the multiple candidate metadata fields for any target execution logic element among multiple execution logic elements, based on the intent semantic matching results corresponding to each of the multiple candidate metadata fields related to the target execution logic element.

[0228] The second determining subunit is used to determine the first target metadata field that matches other execution logic elements and the field matching result between the target metadata field and the candidate metadata field, wherein the other execution logic elements are execution logic elements that are different from the target execution logic element, and the first target metadata field is the target metadata field that has been generated.

[0229] The first obtaining sub-unit is used to update the matching weights of multiple candidate metadata fields according to the field matching results, so as to obtain the target matching weights of multiple candidate metadata fields.

[0230] The third determining subunit is used to determine the second target metadata field that matches the target execution logic element from multiple candidate metadata fields based on multiple target matching weights.

[0231] According to an embodiment of this application, the identification module includes an identification unit.

[0232] The recognition unit is used to perform intent recognition on the request text using a language model to obtain structured request content, which includes data attribute items and data content related to the metadata in the query statement.

[0233] According to an embodiment of this application, the identification module further includes an update unit.

[0234] The update unit is used to semantically update the requirement text using a language model to obtain the target requirement text. The target requirement text represents at least one requirement content based on a specified tag. The target requirement text is used to semantically understand the requirement intent based on the associated specified tag and requirement content prompting language model.

[0235] According to an embodiment of this application, the demand intent also includes the demand complexity determined by semantic understanding of the demand text through a language model. The demand complexity represents the complexity of the execution process of the query statement. The demand complexity is used to prompt the language model to process the demand intent based on the thought process topology that matches the demand complexity, thereby obtaining the execution logic structure.

[0236] According to an embodiment of this application, the execution logic structure acquisition module includes: a third determining unit and a second output unit.

[0237] The third determining unit is used to determine the topology of the thinking process by using a language model to plan tasks based on the content of the requirements in the requirements intent, based on the complexity of the requirements. In this topology, multiple thinking tasks have dependencies, and the number of thinking tasks matches the complexity of the requirements.

[0238] The second output unit is used to perform multiple thinking tasks based on dependencies using the language model and output the execution logic structure.

[0239] According to embodiments of this application, the requirement intent to satisfy preset requirement conditions includes: requirement complexity is greater than or equal to a preset complexity threshold.

[0240] According to embodiments of this application, the query statement generation apparatus further includes an intent pattern information determination module and a semantic understanding module.

[0241] The intent pattern information determination module is used to determine intent pattern information that matches the textual semantics of the demand intent representation from the preset database pattern information in response to the demand complexity being less than a preset complexity threshold.

[0242] The semantic understanding module is used to perform semantic understanding using language model demand intent and intent pattern information, output multiple intent intermediate structured data to describe the query statement, and generate a reference query statement based on the multiple intent intermediate structured data.

[0243] According to embodiments of this application, the intent pattern information includes an intent metadata field that matches the demand intent;

[0244] The semantic understanding module includes a semantic understanding unit and an intent intermediate structured data determination unit.

[0245] The semantic understanding unit is used to perform semantic understanding using the language model's demand intent and intent metadata fields to obtain the associated intent identifier and intent metadata fields.

[0246] The intent intermediate structured data determination unit is used to determine the intent intermediate structured data based on the associated intent identifier and intent metadata fields.

[0247] According to an embodiment of this application, the query statement generation device further includes a third verification module and a fourth verification module.

[0248] The third verification module is used to verify multiple execution logic elements in the execution logic structure based on the business data attributes in the business rules related to the requirement text, and obtain semantic verification results. The semantic verification results represent the semantic consistency between the execution logic elements and the business data attributes.

[0249] The fourth verification module is used to verify the dependency relationship between multiple execution logic elements based on the accounting rules in the business rules, and obtain the accounting logic verification result. The accounting logic verification result indicates whether the structured relationship meets the accounting execution logic represented by the accounting rule. The defect information represented by the semantic verification result and the accounting logic verification result is used to prompt the language model to update the current execution logic structure and obtain the updated execution logic structure.

[0250] According to embodiments of this application, the execution logic element includes at least one of the following: a time attribute element representing time conditions; a region attribute element representing region conditions; and an indicator type element representing the calculated indicator in the demand intent.

[0251] According to an embodiment of this application, the query statement generation module includes a generation unit.

[0252] The generation unit is used to process multiple intermediate structured data based on domain-specific language format attributes using a language model to generate query statements.

[0253] According to embodiments of this application, any multiple modules among the identification module 810, execution logic structure acquisition module 820, target pattern information acquisition module 830, intermediate structured data acquisition module 840, and query statement generation module 850 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the identification module 810, execution logic structure acquisition module 820, target pattern information acquisition module 830, intermediate structured data acquisition module 840, and query statement generation module 850 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, or firmware, or in any appropriate combination of any of these three implementation methods. Alternatively, at least one of the identification module 810, the execution logic structure acquisition module 820, the target pattern information acquisition module 830, the intermediate structured data acquisition module 840, and the query statement generation module 850 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0254] Figure 9 A block diagram of an electronic device suitable for implementing a query statement generation method according to an embodiment of this application is shown.

[0255] like Figure 9As shown, an electronic device 900 according to an embodiment of this application includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage portion 908 into a random access memory (RAM) 903. The processor 901 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 901 may also include onboard memory for caching purposes. The processor 901 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0256] RAM 903 stores various programs and data required for the operation of electronic device 900. Processor 901, ROM 902, and RAM 903 are interconnected via bus 904. Processor 901 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 902 and / or RAM 903. It should be noted that programs may also be stored in one or more memories other than ROM 902 and RAM 903. Processor 901 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0257] According to embodiments of this application, the electronic device 900 may further include an input / output (I / O) interface 905, which is also connected to a bus 904. The electronic device 900 may also include one or more of the following components connected to the input / output (I / O) interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the input / output (I / O) interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0258] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0259] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 902 and / or RAM 903 and / or one or more memories other than ROM 902 and RAM 903 described above.

[0260] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the query statement generation method provided in the embodiments of this application.

[0261] When the computer program is executed by the processor 901, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0262] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 909, and / or installed from a removable medium 911. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0263] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 909, and / or installed from the removable medium 911. When the computer program is executed by the processor 901, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0264] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0265] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0266] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

[0267] The embodiments of this application have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of this application. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Without departing from the scope of this application, those skilled in the art can make various substitutions and modifications, all of which should fall within the scope of this application.

Claims

1. A method for generating query statements, characterized in that, include: Based on business data, the intent of the requirement text is identified to obtain the requirement intent. In response to the requirement intent satisfying the preset requirement conditions, the requirement intent is processed using a language model to obtain an execution logic structure. The execution logic structure includes multiple execution logic elements based on structured representation. The execution logic elements represent the target task of the query statement or the target metadata related to the target task based on text semantic representation. The structured relationship between the multiple execution logic elements represents the execution process of the query statement. Target pattern information that matches the text semantics represented by the execution logic element is determined from preset database pattern information, wherein the target pattern information includes a target metadata field corresponding to the execution logic element; Based on the target metadata field as prompt information, the language model is used to process multiple execution logic elements, and the associated identifier and target metadata field are output; Based on the associated identifier and target metadata field, multiple intermediate structured data are output, which are represented by domain-specific language format attributes and are used to describe the query statement. The query statement is generated based on the multiple intermediate structured data sets. The language model outputs the intermediate structured data by performing the following operations: Semantic understanding is performed on the task type elements that represent the target task type to obtain an identifier that matches the target task type; The task entity element representing the target metadata is semantically transformed to determine the target metadata field corresponding to the task entity element; Based on the structured relationship between the task type element and the task entity element, associated identifiers and target metadata fields are determined, wherein the intermediate structured data is determined based on the associated identifiers and target metadata fields.

2. The method according to claim 1, characterized in that, The method further includes: Based on the preset metadata fields in the preset database schema information, the target metadata fields in the intermediate structured data are subjected to consistency verification to obtain the consistency verification result. The attribute information corresponding to the target metadata field in the intermediate structured data is validated to obtain the attribute compliance validation result; The defect information represented by the consistency verification result and the attribute compliance verification result is used to prompt the language model to update the current intermediate structured data, thereby obtaining the updated intermediate structured data.

3. The method according to claim 1, characterized in that, Determining target pattern information from preset database pattern information that matches the text semantics represented by the execution logic element includes: Based on semantic matching between the execution logic element and preset database schema information, multiple candidate metadata fields related to the execution logic element are obtained, wherein the candidate metadata fields represent database objects in the preset database schema information; and Based on the intent semantic matching result between the candidate metadata fields and the demand intent, a target metadata field that matches the execution logic element is determined from multiple candidate metadata fields, and the target pattern information includes the target metadata field.

4. The method according to claim 3, characterized in that, Based on the intent semantic matching result between the candidate metadata fields and the demand intent, a target metadata field matching the execution logic element is determined from multiple candidate metadata fields, including: For any target execution logic element among the multiple execution logic elements, the matching weight of each of the multiple candidate metadata fields is determined based on the intent semantic matching result corresponding to each of the multiple candidate metadata fields related to the target execution logic element. Determine the field matching result between the first target metadata field that matches other execution logic elements and the candidate metadata field, wherein the other execution logic elements are execution logic elements that are different from the target execution logic element, and the first target metadata field is the target metadata field that has been generated. Update the matching weights of the candidate metadata fields according to the field matching results to obtain the target matching weights of the candidate metadata fields; and Based on multiple target matching weights, a second target metadata field that matches the target execution logic element is determined from multiple candidate metadata fields.

5. The method according to claim 1, characterized in that, Perform intent recognition on the requirement text to obtain the requirement intent, including: The language model is used to perform intent recognition on the request text to obtain structured request content, wherein the structured request content includes data attribute items and data content related to the metadata in the query statement, and the request intent includes the request content.

6. The method according to claim 5, characterized in that, The process of performing intent recognition on the requirement text to obtain the requirement intent also includes: The language model is used to semantically update the requirement text to obtain the target requirement text, wherein the target requirement text represents at least one requirement content based on a specified tag, and the target requirement text is used to semantically understand the requirement intent based on the associated specified tag and requirement content prompting language model.

7. The method according to claim 1 or 5, characterized in that, The demand intent also includes the demand complexity determined by semantic understanding of the demand text through the language model, whereby the demand complexity represents the complexity of the execution process of the query statement; The requirement complexity is used to prompt the language model, and the requirement intent is processed based on the thought process topology that matches the requirement complexity to obtain the execution logic structure.

8. The method according to claim 7, characterized in that, The required intent is processed using a language model to obtain the execution logic structure, including: Based on the aforementioned requirement complexity, the language model is used to perform task planning on the requirement content within the requirement intent, thereby determining the topology of the thinking process. Multiple thinking tasks within this topology are dependent on each other, and the number of thinking tasks matches the requirement complexity. The language model is used to perform multiple thinking tasks based on the dependencies, and the execution logic structure is output.

9. The method according to claim 8, characterized in that, The requirement intent satisfies the preset requirement conditions, including: the requirement complexity is greater than or equal to a preset complexity threshold.

10. The method according to claim 7, characterized in that, The method further includes: In response to the requirement complexity being less than a preset complexity threshold, intent pattern information matching the textual semantics of the requirement intent representation is determined from the preset database pattern information; and The language model is used to perform semantic understanding of the demand intent and the intent pattern information, outputting multiple intermediate structured data of intent to describe the query statement, and generating a reference query statement based on the multiple intermediate structured data of intent.

11. The method according to claim 10, characterized in that, The intent pattern information includes intent metadata fields that match the demand intent; Specifically, semantic understanding is performed using the demand intent and intent pattern information from the language model to output multiple intermediate structured data of intents describing the query statement, including: Using the language model, semantic understanding is performed on the demand intent and the intent metadata field to obtain the associated intent identifier and intent metadata field; and Based on the associated intent identifier and intent metadata fields, the intermediate structured data of the intent is determined.

12. The method according to claim 1, characterized in that, The method further includes: Based on the business data attributes in the business rules related to the requirement text, multiple execution logic elements in the execution logic structure are verified to obtain a semantic verification result. The semantic verification result represents the semantic consistency between the execution logic element and the business data attribute. Based on the accounting rules in the business rules, the dependency relationships between multiple execution logic elements are verified by accounting logic rules to obtain accounting logic verification results. The accounting logic verification results indicate whether the structured relationship satisfies the accounting execution logic represented by the accounting rules. The defect information represented by the semantic verification result and the accounting logic verification result is used to prompt the language model to update the current execution logic structure, thereby obtaining the updated execution logic structure.

13. The method according to claim 1, characterized in that, The execution logic element includes at least one of the following: Time attribute elements that represent time conditions; Regional attribute elements that characterize regional conditions; The indicator type element that represents the calculated indicators in the demand intent.

14. The method according to claim 1, characterized in that, The query statement is generated based on multiple sets of intermediate structured data, including: The query statement is generated by processing multiple intermediate structured data represented by domain-specific language format attributes using a language model.

15. A query statement generation device, characterized in that, include: The recognition module is used to identify the intent of the requirement text based on business data to obtain the requirement intent. An execution logic structure acquisition module is used to process the demand intent using a language model in response to the demand intent satisfying a preset demand condition, and obtain an execution logic structure. The execution logic structure includes multiple execution logic elements based on structured representation. The execution logic elements represent the target task of the query statement or the target metadata related to the target task based on text semantic representation. The structured relationship between the multiple execution logic elements represents the execution process of the query statement. The target pattern information acquisition module is used to determine target pattern information that matches the text semantics represented by the execution logic element from the preset database pattern information; The intermediate structured data acquisition module is used to utilize the language model to perform semantic understanding on multiple execution logic elements and target pattern information, and output multiple intermediate structured data to describe the query statement. A query statement generation module is used to generate the query statement based on multiple intermediate structured data. The target pattern information includes a target metadata field corresponding to the execution logic element; the intermediate structured data acquisition module is configured as follows: Based on the target metadata field as prompt information, the language model is used to process multiple execution logic elements, and the associated identifier and target metadata field are output; Based on the associated identifier and target metadata field, multiple intermediate structured data are output, which are represented by domain-specific language format attributes and are used to describe the query statement. The language model outputs the intermediate structured data by performing the following operations: Semantic understanding is performed on the task type elements that represent the target task type to obtain an identifier that matches the target task type; The task entity element representing the target metadata is semantically transformed to determine the target metadata field corresponding to the task entity element; Based on the structured relationship between the task type element and the task entity element, associated identifiers and target metadata fields are determined, wherein the intermediate structured data is determined based on the associated identifiers and target metadata fields.

16. An electronic device comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 14.

17. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 14.

18. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 14.

Images