Data query method and system, and related device

Abstract

Disclosed are a data query method and system, and a related device, relating to the field of artificial intelligence. The method comprises the following steps: a data query system acquires input data; obtains, on the basis of the input data, metrics to be queried as requested by a user; uses, on the basis of said metrics, a multi-agent collaborative processing strategy to confirm a data query result, the multi-agent collaborative processing strategy being used for indicating a manner of implementing data retrieval on the basis of at least one of a graph model and a vector database; and presents the data query result, wherein the graph model expresses, in a graph-based form, correspondences between the metrics and between the metrics and database table data, and the vector database expresses, in a vector-based form, descriptive texts and computational formulas of the metrics. In this way, even if the expression of input data differs from the expression of fields in the database, or if metrics to be read are not present in the database, corresponding SQL statements can still be obtained by means of the graph model or the vector database, thereby reducing the error rate of natural language query, and meeting the query requirements of users.

Description

A data query method, system and related equipment

[0001] This application claims priority to Chinese Patent Application No. 202411039113.2, filed with the China National Intellectual Property Administration on July 30, 2024, entitled "A Data Query Method, System and Related Equipment", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of artificial intelligence (AI), and in particular to a data query method, system, and related equipment. Background Technology

[0003] Natural Language to Structured Query Language (NL2SQL) technology refers to the technique of converting natural language query text into structured query language (SQL) statements, and then using SQL statements to query the database and obtain the query results. Typically, the NL2SQL process includes the following steps: parsing the user-input query text to understand its key information; mapping the parsed key information to table data in the database; constructing an SQL statement based on the key information and the mapped table data; and then using the SQL statement to complete the query in the database and obtain the query results. This technology allows users to query databases using natural language without needing to master complex database languages ​​like SQL, thus significantly lowering the technical barrier to database queries. Even users without a technical background can easily and quickly retrieve the data they need from the database.

[0004] However, database tables and fields are usually designed according to business needs, while user input in natural language is more flexible. The same query intent can be expressed in various natural language texts. This means that the diversity of expression methods may cause the system to be unable to find the corresponding table and field in the database after obtaining the key information corresponding to the natural language query. Consequently, it may be unable to generate the correct SQL statement and return the correct query results to the user. This results in a high error rate in the query results obtained from natural language queries, making it difficult to meet the user's query needs. Summary of the Invention

[0005] This application provides a data query method, system, and related equipment to solve the problem that the current natural language text-to-SQL conversion has a high error rate and is difficult to meet users' needs for completing database queries using natural language.

[0006] Firstly, a data query method is provided, which includes the following steps: the data query system obtains input data, including user data to be queried; obtains the query index requested by the user based on the input data; confirms the data query result using a multi-agent collaborative processing strategy based on the query index; the multi-agent collaborative processing strategy is used to indicate at least one method of data retrieval based on a graph model and a vector library; and presents the data query result.

[0007] The above method utilizes a multi-agent collaborative processing strategy, employing at least one of a graph model or a vector library to complete data queries. The graph model expresses the correspondence between indicators and between indicators and database table data in a graph format, while the vector library expresses the descriptive text and calculation formulas of the indicators in a vector format. This ensures that even if the input data is expressed differently from the fields in the database, or if the indicator requested by the input data does not exist in the database and requires calculations using some fields from the database, the corresponding SQL statements can be obtained through the graph model or vector library. This allows users to flexibly and without restrictions input natural language text to complete queries, reducing the error rate of natural language queries and meeting user query needs.

[0008] In one possible implementation, the graph model includes mapping relationships between multiple metrics and table data in the database. When confirming the data query results using a multi-agent collaborative processing strategy based on the metrics to be queried, the metrics to be queried can be searched in the graph model first. If the graph model includes the metrics to be queried, the query logic of the metrics to be queried can be obtained based on the mapping relationships. Based on the query logic, the structured query SQL statement for the input data can be determined, and the SQL statement can be executed to obtain the data query results.

[0009] The above implementation establishes multiple semantic indicators through a graph model, creating a correspondence between these indicators and table data in the database. This allows the user's input data to be matched against the graph model to obtain the query logic within the input data. The system then generates SQL statements based on this query logic. This eliminates the need for natural language processing of the input data, allowing the system to directly obtain the query logic through simple matching. This not only improves query efficiency but also enhances the accuracy of the SQL statements and improves the user experience.

[0010] In one possible implementation, the graph model may include a metadata layer. This metadata layer records the initial mapping between metadata and table data. The metadata in the metadata layer describes the table data, which is data from the database. This metadata may include table structure information and address information for the table data. The table structure information may include one or more of the following: database name, table name, and field names. A single table data entry may include multiple fields; therefore, a single table data entry can correspond to multiple metadata entries.

[0011] The above implementation establishes a first mapping relationship between table data and metadata through the metadata layer, enabling the graph model to be built based on metadata rather than table data. This decouples the physical table from the graph model 201. If the physical table data changes, the graph model can adapt to new data structures, field changes, or other types of changes by adjusting the metadata, without needing to redesign or modify the graph model. The existence of the metadata layer can improve the flexibility and adaptability of the graph model and reduce maintenance costs.

[0012] In one possible implementation, the graph model may include a semantic layer, which records a second mapping between each node (metric) and metadata, and also records a third mapping between metrics.

[0013] Optionally, the metrics in the semantic layer may include metrics with the same semantics as the metadata. The node corresponding to the metric establishes a second mapping relationship with the metadata. This second mapping relationship may be a semantic mapping relationship, indicating that the two have the same semantics.

[0014] Optionally, the metrics in the semantic layer may include the results calculated from multiple fields. The node corresponding to the metric establishes a second mapping relationship with multiple metadata. This second mapping relationship may be a computational mapping relationship, indicating that there is computational logic between the two.

[0015] Optionally, the metrics in the semantic layer may include the results of calculations of multiple other metrics. The node corresponding to the metric establishes a third mapping relationship with multiple other nodes. This third mapping relationship may be a calculation mapping relationship. The multiple other nodes may include the nodes that have the same semantics as the metadata, or nodes that are calculated from the multiple fields mentioned above. This application does not make any specific limitations.

[0016] The above implementation method creates some commonly used indicators at the semantic layer and establishes a mapping relationship between these commonly used indicators and metadata, or between indicators. This allows user input data to obtain query logic from the input data through a matching graph model. The query logic includes table data and calculation logic, which can be easily translated into SQL statements. This not only improves query efficiency but also improves the accuracy of SQL statements, thus enhancing the user experience.

[0017] In one possible implementation, the vector library includes descriptive text and calculation formulas for multiple indicators. If the graph model does not include the indicator to be queried, the indicator to be queried is searched in the vector library to obtain prompt information for the indicator to be queried. The prompt information includes the descriptive text and calculation formula of the indicator to be queried. The prompt information is input into the large language model to obtain the SQL statement of the input data. The SQL statement is executed to obtain the data query results.

[0018] In practice, the descriptive text in the vector library includes the semantic interpretation of the same indicator under different expressions, as well as the textual description of the calculation logic under different expressions. The calculation formula in the vector library includes the calculation formula of the same indicator under different calculation methods.

[0019] It should be understood that while obtaining SQL based on graph models offers high matching efficiency and accuracy, it requires pre-establishing a mapping relationship between table data and metrics. Some less frequently used metrics may not be able to generate SQL using graph models. Conversely, obtaining SQL based on vector libraries, although requiring the use of large language models for generation and thus having lower matching efficiency compared to graph models, leverages the generation capabilities of large language models to generate SQL for some less frequently used metrics. Therefore, combining graph models and vector libraries allows for the generation of corresponding query results for both commonly used and less frequently used metrics, meeting various user needs. Less frequently used metrics can be stored in vector libraries. These libraries do not need to store complete mapping relationships; they only need to store the metric formulas or descriptive text. This allows for more efficient management and storage of abstract representations of a large number of metrics. In this way, commonly used metrics can be directly mapped from graph models, while less frequently used metrics are indirectly mapped through vector libraries, thereby reducing the overall computational and storage burden.

[0020] In one possible implementation, when inputting the prompt information into the large language model to obtain the structured query SQL statement of the input data, the sub-indicators of the query indicator can be obtained based on the descriptive text and calculation formula in the prompt information. The sub-indicators are used to calculate the query indicator, or the sub-indicators are semantically similar to the query indicator. The sub-indicators are searched in the graph model. If the graph model does not include sub-indicators, the prompt information is input into the large language model to obtain the structured query SQL statement of the input data.

[0021] Furthermore, when the graph model includes sub-indicators, the query logic of the sub-indicators is obtained based on the mapping relationship between the sub-indicators and table data. Based on the query logic of the sub-indicators and the prompt information, the query logic of the indicator to be queried is determined. Based on the query logic of the indicator to be queried, the SQL statement is determined, and the SQL statement is executed to obtain the data query results.

[0022] In practice, if the description text of the metric to be queried is a semantic explanation or a synonym explanation of the metric to be queried, and the sub-metric is a synonym of the metric to be queried, then the graph model includes the sub-metric. The query logic of the sub-metric can be obtained based on the graph model. Based on the query logic and the translation model, the SQL statement can be obtained.

[0023] If the description text of the metric to be queried is a semantic interpretation of the calculation logic of the metric to be queried, multiple sub-metrics can be obtained based on this calculation logic. If the graph model includes multiple sub-metrics, the query logic of multiple sub-metrics can be obtained based on the graph model. Then, based on the query logic of multiple sub-metrics and the calculation logic between multiple sub-metrics recorded in the description text, the query logic of the metric to be queried can be obtained. This query logic is input into the translation model to obtain the SQL statement.

[0024] If the graph model only includes some of the indicators from multiple sub-indicators, the table data of these indicators can be determined based on the graph model, and this data can be added to the prompt information as relevant table information. Then, the prompt information can be input into the large language model to obtain the SQL statement.

[0025] If the graph model does not include the above sub-indicators, you can input the descriptive text or calculation formula as prompts into the large language model to obtain the SQL statement.

[0026] The above implementation method records a large number of semantic metrics and semantic metadata in the graph model, and records the mapping relationship between metrics and metadata, metadata and physical table data. The graph model is combined with a vector library to generate prompt information, which can help the large language model better understand the semantics of the input data and the data structure of the database, thereby generating more accurate SQL statements.

[0027] In one possible implementation, the method further includes the following steps: determining the user's intent based on the input data, where the intent includes an analysis intent; obtaining the analysis model corresponding to the analysis intent; inputting the data query results into the analysis model; obtaining the analysis results; and presenting the analysis results.

[0028] In practical implementation, if the user's input data contains a data analysis intent, the corresponding analysis model can be determined based on that intent. Then, the analysis model is used to obtain the analysis results, and a response text corresponding to the input data is generated based on these results. Therefore, the data query system 200 can train multiple analysis models based on the user's possible analysis intents, with each model corresponding to a specific analysis intent. Each analysis model is used to handle a data analysis task corresponding to a particular analysis intent. Analysis models may include, but are not limited to, business data analysis, tax case analysis, and tax audit case analysis; this application does not impose specific limitations.

[0029] The above implementation method, by pre-establishing multiple analysis models, enables users' input data not only to be used for data queries through natural language, but also to perform data analysis tasks such as predictive analysis and anomaly analysis through natural language, thus meeting users' various usage needs and improving the user experience.

[0030] In one possible implementation, the data query system can be based on the AutoGen framework, which can include multiple agents. Each agent can be a program or component with specific functions, capable of making decisions and taking actions based on input. Each agent is customizable and has the ability to communicate with each other. The configured agents can interact, forming the basic logic of a multi-agent collaborative processing strategy. When the system receives user input data, multiple agents can automatically run and communicate with each other, enabling the data query system to obtain the response text corresponding to the input data based on the multi-agent collaborative processing strategy.

[0031] For example, agent1 is used to determine the query logic based on the graph model, or to determine the prompt information based on the vector library. agent2 is used to determine the SQL statement based on the query logic or prompt information, and execute the SQL statement to generate query results. agent3 is used to determine whether there is an analytical intent based on the input data. If there is an analytical intent, the analytical model is used on the query results to obtain analytical results.

[0032] For another example, agent1 is used to determine the query logic based on the graph model, translate the query logic to generate SQL statements, agent2 is used to determine the prompt information based on the vector library, input the prompt information into the large language model to generate SQL statements, and agent3 is used to determine whether there is an analysis intent based on the input data. If there is an analysis intent, the analysis model is used to obtain the analysis results from the query results.

[0033] It should be noted that the above agent allocation method is an example. Each agent is a customizable program or component that can communicate with each other and has specific functions, so agents can be flexibly allocated according to business needs.

[0034] The above implementation method creates multiple agents through the AutoGen framework, and configures corresponding functions for each agent according to actual business needs. The agents can automatically execute tasks and automatically obtain the response text corresponding to the input data based on the multi-agent collaborative processing strategy.

[0035] In a second aspect, a data query system is provided, the data query system comprising modules for executing the data query method in the first aspect or any possible implementation thereof.

[0036] Thirdly, a computing device is provided, the computing device including a processor and a memory, the memory for storing instructions and the processor for executing the instructions, such that the computing device implements the method described in the first aspect.

[0037] Fourthly, a computer-readable storage medium is provided, wherein instructions are stored in the computer-readable storage medium, and the instructions are executed by a computing device or a cluster of computing devices to implement the method described in the first aspect.

[0038] Fifthly, a computing device cluster is provided, the computing device cluster including at least one computing device, each computing device including a processor and a memory, the processor of the at least one computing device being configured to execute instructions stored in the memory of the at least one computing device, such that the computing device cluster implements the method described in the first aspect.

[0039] In a sixth aspect, a computer program product comprising instructions is provided, the computer program product including instructions capable of running on a computing device or stored in any available medium, and when the computer program product is run on a computing device or a cluster of computing devices, causing the computing device or cluster of computing devices to perform the method described in the first aspect.

[0040] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0041] Figure 1 is an architecture diagram of a data query system provided in this application;

[0042] Figure 2 is an example diagram of a data query system provided in this application deployed in a cloud environment;

[0043] Figure 3 is a flowchart illustrating the steps of a data query method provided in this application during the configuration phase.

[0044] Figure 4 is an example diagram of a graphical model provided in this application;

[0045] Figure 5 is an example diagram of a vector library provided in this application;

[0046] Figure 6 is an example diagram of the processing logic of a translation model provided in this application;

[0047] Figure 7 is an example diagram of an analysis model provided in this application;

[0048] Figure 8 is a flowchart illustrating the steps of a data query method provided in this application during the application stage.

[0049] Figure 9 is an exemplary interface of a data query method provided in this application;

[0050] Figure 10 is a schematic diagram of the structure of a data query system provided in this application;

[0051] Figure 11 is a schematic diagram of the structure of a computing device provided in this application;

[0052] Figure 12 is an example diagram of a computing device cluster provided in this application;

[0053] Figure 13 is a schematic diagram of another computing device cluster provided in this application. Detailed Implementation

[0054] First, the application scenarios involved in this application will be explained.

[0055] Currently, when users query data in a database, they need to interact with the database using a database language (such as SQL). This requires users without a technical background to learn database languages ​​before they can use the database to complete queries, increasing the learning curve. To solve this problem, NL2SQL technology emerged. This technology refers to converting the user's natural language query into an SQL statement, and then using the SQL statement to query the database to obtain the results. Typically, the NL2SQL process is as follows: parsing the user's query text to understand the key information, mapping the parsed key information to table data in the database, constructing an SQL statement based on the key information and the mapped table data, and then using the SQL statement to complete the query in the database to obtain the results. This technology allows users to query the database using natural language without needing to master database languages ​​such as SQL, thus significantly lowering the technical barrier to database queries. Users without a technical background can easily and quickly retrieve the data they need from the database.

[0056] However, database tables and fields are usually designed according to business needs, while user input in natural language is more flexible. The same query intent can be expressed in various natural language texts. This means that the diversity of expression methods may cause the system to be unable to find the corresponding table and field in the database after obtaining the key information corresponding to the natural language query, and thus be unable to generate the correct SQL statement.

[0057] For example, a user inputs a word that has a corresponding field in the database. However, the word input by the user differs from the field name in the database. For instance, a user might ask "What is employee A's monthly salary?" The key information is "employee A" and "monthly salary." However, the database only has a monthly income table, which includes "employee name" and "monthly income" fields, or it might only include "name" and "income" fields. The key information "monthly salary" and the fields "monthly income" and "income" actually have the same meaning, but the two expressions are inconsistent, causing the system to be unable to complete the mapping between the key information and the table data, and thus unable to generate an SQL statement.

[0058] For another example, the words entered by the user may not have a direct corresponding field in the database, but the result can be obtained through calculations using some fields in the database. For instance, if a user asks, "What is the profit of product X in January?", the key information is "product X", "January", and "profit". The database contains cost tables and sales tables for product X in January. Based on the "cost" and "sales", the "profit" that the user wants can be calculated. However, because the database does not have a profit table, the system cannot complete the mapping between the key information and the table data, and therefore cannot generate an SQL statement.

[0059] In summary, current NL2SQL technology relies on the mapping between query text and table data in the database to complete the conversion between natural language and SQL. However, due to the diversity of natural language text expression, keywords in the query text may not be able to be mapped to fields in the database, causing the system to be unable to generate the correct SQL statement corresponding to the query text and return the correct query results to the user. This results in a high error rate in the query results obtained from natural language queries, making it difficult to meet the user's query needs.

[0060] To address the high error rate of current natural language text-to-SQL conversion, which fails to meet users' needs for database queries using natural language, this application provides a data query system method. This method utilizes a multi-agent collaborative processing strategy and leverages at least one of graph models or vector libraries to complete data queries. The graph model expresses the correspondence between indicators and between indicators and database table data in a graph format, while the vector library expresses the descriptive text and calculation formulas of the indicators in a vector format, enabling users to query the desired data regardless of the natural language they use.

[0061] Specifically, after obtaining the requested indicator based on the user's input data, the data query system first searches for the indicator in the graph model to obtain the physical table data mapped to that indicator, and then obtains the indicator query logic to generate the SQL statement corresponding to the input data. If the indicator is not found in the graph model, it searches for the indicator in the vector library to obtain the indicator's descriptive text, which is then input as a prompt into the large language model to obtain the corresponding SQL statement. This ensures that even if the input data is expressed differently from the fields in the database, or if the indicator requested by the input data does not exist in the database and requires a series of calculations using some fields from the database, the corresponding SQL statement can be obtained through the graph model or vector library. This allows users to flexibly and without restrictions input natural language text to complete queries, reducing the error rate of natural language queries and meeting user query needs.

[0062] Figure 1 is an architecture diagram of a data query system provided in this application. As shown in Figure 1, the architecture includes a client 100, a data query system 200, and a database 300. The number of clients 100 and databases 300 that establish communication connections with the data query system 200 can be one or more. Figure 1 is illustrated by taking one client 100 and one database 300 as an example. This application does not make any specific limitations.

[0063] The data query system 200 and the database 300 establish a communication connection via a network. This network may include an internal network, such as a local area network (LAN) or a dedicated line, or an encrypted public network, such as a virtual private network (VPN), thereby achieving secure communication between the data query system 200 and the database 300. Other network types may also be included, and this application does not specifically limit them. The network between the client 100 and the data query system may include the internet, a wireless local area network (Wi-Fi), a cellular network, or other network types, and this application does not specifically limit them.

[0064] Client 100 is deployed on terminal devices or computing devices to enable human-computer interaction. Terminal devices include personal computers, smartphones, wearable devices, handheld processors, tablets, mobile laptops, augmented reality (AR) devices, virtual reality (VR) devices, smart conferencing devices, etc., without specific limitations here. The description of computing devices can be found above and will not be repeated here. Computing devices can be bare metal servers (BMS), virtual machines, containers, or storage devices. BMS refers to a general-purpose physical server, such as an ARM server or an x86 server; a virtual machine refers to a complete computer system simulated by software, possessing full hardware system functionality and running in a completely isolated environment. Any task that can be performed on a physical computer can also be performed in a virtual machine. When creating a virtual machine on a computing device, a portion of the physical machine's hard drive and memory capacity needs to be used as the virtual machine's hard drive and memory capacity. Each virtual machine has its own independent basic input / output system (BIOS), hard disk, and operating system, and can be operated like a physical machine. A container is a portable software unit that can combine an application and all its dependencies into a single software package. This package is not limited by the underlying host operating system, thus eliminating the need to build complex environments and simplifying the application development and deployment process.

[0065] The data query system 200 and database 300 can be deployed on computing devices, or on a cluster of computing devices composed of multiple computing devices. The description of the computing devices is as described above and will not be repeated here. The database 300 can also be deployed on storage devices or storage arrays. Storage devices can include individual hardware storage devices, such as hard disk drives (HDDs), solid-state drives (SSDs), mechanical hard disks (HDDs), USB flash drives (universal serial buses), flash memory, SD cards (secure digital memory cards), Memory Sticks, etc., without specific limitations in this application. Storage arrays can be redundant arrays of independent disks (RAID), network attached storage (NAS), storage area networks (SANs), etc., without specific limitations in this application. Storage devices can also include virtual storage devices, such as cloud storage services provided by cloud data centers, without specific limitations in this application.

[0066] Optionally, the client 100 and the data query system 200 may be deployed on the same computing device, or the client 100 and the data query system 200 may be deployed on different computing devices in the same computing device cluster, or the client 100 and the data query system 200 may be deployed on different computing devices in different computing device clusters. This application does not make any specific limitations.

[0067] Optionally, the database 300 and the data query system 200 may be deployed on the same computing device, or on different computing devices in the same computing device cluster, or on different computing device clusters. Alternatively, the database 300 may be deployed on a storage device and the data query system 200 may be deployed on a computing device. The storage device and the computing device may belong to the same or different computing device clusters. This application does not make any specific limitations.

[0068] Optionally, client 100 can be software or an application running on a user-controlled terminal device or computing device, such as a personal computer (PC) client, a web client accessed via a browser, an application (APP) client running on a mobile terminal, or a cloud platform console; this application does not impose specific limitations. Users holding client 100 can be users who need to complete data queries or data analysis through natural language, such as financial staff, IT staff, and business personnel of an enterprise; this application does not impose specific limitations.

[0069] In practice, Client 100 is applied to fields with data analysis and query needs, such as data analysis, data mining, data exploration, and data querying. These include, but are not limited to, the biomedical field (e.g., epidemiological research, drug development), the financial field (business data analysis, tax case analysis, risk assessment, market forecasting), the social media field (personalized recommendation, advertising positioning, sentiment analysis), and the sales field (pricing strategy, inventory management, customer relationship management). It can also be applied to many other fields with data analysis needs, which will not be listed here.

[0070] Optionally, client 100 may be a client specifically designed for database querying and / or data analysis. The type of client 100 and the type of user may differ across different data analysis fields. For example, in the biomedical field, client 100 may be a bioinformatics tool, statistical analysis software, etc., used to process and analyze biological data such as genomics, proteomics, and gene expression. In the social media field, client 100 may be a data mining tool, social media analysis platform, etc., used to discover public opinion trends, user interactions, and sentiment analysis from social media data. In the financial field, client 100 may be a financial modeling tool, risk analysis tool, etc., used for market analysis, portfolio optimization, and risk management. In the sales field, client 100 may be an inventory management tool, pricing analysis tool, etc., used for optimizing inventory, supply chain analysis, and formulating product pricing strategies. It should be understood that the above examples are for illustrative purposes only and this application does not impose specific limitations.

[0071] Optionally, the client 100 can be a standalone client specifically designed for data analysis functions, or it can be a data analysis function module or plugin within comprehensive software, such as the data analysis and query modules within data mining software, or the financial analysis assistant and data query assistant in commonly used enterprise (office automation, OA) clients. This application does not impose any specific limitations.

[0072] Optionally, client 100 can also be a cloud platform client, such as a cloud platform console, specifically a web-based console. Client 100 can also serve as a service interface for the data query system 200 and / or database 300 to provide services externally, allowing users to access the corresponding services by calling this service interface. The service interface includes at least one of the following forms: Software Development Kit (SDK) or Application Programming Interface (API). Further, the aforementioned client 100 can provide data analysis-related cloud services to management users, who can obtain access to the data query system 200 provided in this application by purchasing cloud services. Alternatively, the cloud platform provides a comprehensive service to users, and the data query method provided in this application can be a sub-service within that comprehensive cloud service. For example, if the comprehensive service is a database cloud service, the data query method in this application can be a sub-service within a data mining service; this application does not impose specific limitations.

[0073] The preceding text described in detail the possible deployment methods for the data query system 200, database 300, and client 100. In actual deployment, flexible deployment can be carried out based on specific application scenarios and business needs. The following section provides examples of actual deployment methods for the data query system 200, database 300, and client 100 in specific application scenarios.

[0074] For example, suppose client 100 can function as an enterprise office assistant or has software deployed with an enterprise office assistant. Employees can use this office assistant for real-time problem solving, technical support, data analysis, and other operations. In this scenario, database 300, data query system 200, and client 100 can be deployed on internal office equipment. For instance, data query system 200 and database 300 could be deployed on a service or server cluster purchased by the enterprise, while client 100 could be deployed on the enterprise's office computers. Employees, as users, can run client 100 on their office computers, and client 100 can send user input data to the data query system. The data query system 200 can execute the data query method provided in this application, generate an SQL statement corresponding to the input data, use the SQL statement to search the database 300 to obtain query results, and then generate a response text based on the query results and send it back to the client 100. The client 100 displays the response text to the user. If the user's input data includes a data analysis intent, then after obtaining the query results, the data query system 200 can perform further data analysis based on the data analysis intent in the input data to obtain analysis results, and then generate a response text based on the query results and analysis results and send it to the client 100. This enables enterprise employees to interact with office assistants based on natural language, realizing functions such as data query, market analysis, portfolio optimization, and risk management.

[0075] In another application scenario, the data query system 200 can be deployed in a cloud environment. For example, Figure 2 is an example diagram of a data query system deployed in a cloud environment according to this application. As shown in Figure 2, a user can initiate a purchase request for a database cloud service through client 100. This database cloud service includes a data query sub-service. After client 100 sends the purchase request to the cloud platform, the cloud platform can provide client 100 with access to the cloud services of data query system 200 and database 300. This allows the user to send input data to data query system 200 through client 100. Data query system 200 can convert the input data into SQL statements and then use these SQL statements to query database 300 to obtain query results. If the user's input data also has the intent of data analysis, data query system 200 can perform further analysis based on the query results to obtain analysis results. Then, based on the query results and analysis results, it generates a response text and sends it back to client 100.

[0076] The cloud platform also maintains various basic resources, including computing resources, storage resources, network resources, and security resources, to meet the computing needs of the data query system 200 under different scales and loads. Furthermore, these computing resources can be dynamically scaled according to the usage needs of the data query system 200 to ensure the stable operation of the data query system 200 and provide users with reliable data query services.

[0077] Optionally, the database 300 and the data query system 200 can be services provided by the same cloud platform. In this case, the cloud platform shown in Figure 2 includes both the database 300 and the data query system 200. Alternatively, the database 300 and the data query system 200 can be services provided by different cloud platforms. In this case, a hybrid cloud architecture can be used to achieve data communication between the data query system 200 and the database 300. That is, the data query system 200 is deployed in data center A, and the database 300 is deployed in data center B. Data center A and data center B communicate with the data query system 200 and the database 300 through their respective cloud platforms to achieve the data query method provided in this application.

[0078] It is worth noting that in the example shown in Figure 2, the data query system 200 is deployed in a cloud environment. Figure 2 is only an exemplary description of the data query system involved in this application, and this application does not make any specific limitations.

[0079] Optionally, the data query system 200 can also be deployed in multiple cloud environments. For example, the graph model 201 and the vector library 202 are deployed in the first cloud environment, the generation model 203 is deployed in the second cloud environment, and the analysis model 204 is deployed in the third cloud environment. The above examples are for illustration only and are not specifically limited in this application.

[0080] Optionally, the data query system 200 can also be implemented through multiple non-cloud environments. For example, the graph model 201, the analysis model 204, and the vector library 202 are deployed on the internal office server of Company A, and the generation model 203 and the analysis model 204 are deployed on the internal office server of Company B. Company A and Company B have a cooperative relationship. The above examples are for illustration only and are not specifically limited in this application.

[0081] Optionally, the data query system 200 can also be deployed in multiple cloud and non-cloud environments. For example, the graph model 201 and the analysis model 204 are deployed on the enterprise's internal office server, the vector library 202 is deployed in the first cloud environment, and the generation model 203 is deployed in the second cloud environment. The above examples are for illustration only and are not intended to limit the scope of the application.

[0082] It should be understood that this application does not limit the number of data query systems 200, or the deployment methods of graph models 201, vector libraries 202, generative models 203, and analytical models 204. For ease of description, the following embodiments use the system structure shown in Figure 2 as an example.

[0083] It should be understood that the above application scenarios are for illustrative purposes only. The data query system 200, database 300, and client 100 can be flexibly deployed according to actual business needs. These will not be illustrated one by one here.

[0084] In this embodiment, the data query system 200 may include a graph model 201, a vector library 202, a generative model 203, and an analytical model 204. The client 100 obtains user input data, which may include query text in natural language, as well as other data such as images, videos, and audio. The client then sends the input data to the data query system 200. The data query system 200 first uses the input data to perform a retrieval in the graph model 201. The graph model 201 includes multiple indicators, each of which has a mapping relationship with table data in the database 300. If an indicator corresponding to the input data is found, query logic can be obtained based on the mapping relationship in the graph model 201. This query logic includes a processing flow and table information. The query logic is then sent to the translation model in the generative model 203. The translation model generates an SQL statement corresponding to the input data based on the query logic, and then uses the SQL statement to query the database 300 to obtain query results. Based on the query results, a response text is generated and fed back to the client 100. If the user's input data has the intent of data analysis, the generation model 203 can send the query results to the analysis model 204. The analysis model 204 generates analysis results based on the query results and generates a response text based on the analysis results to feed back to the client 100.

[0085] Furthermore, if the graph model 201 does not find the indicator corresponding to the input data, the data query system 200 can use the input data to search in the vector library 202. The vector library includes the descriptive text and formulas of the indicators. The data query system 200 can obtain the prompt information of the indicator corresponding to the input data based on the vector library 202. This prompt information includes the descriptive text or calculation formula of the calculation logic between multiple parameters in the indicator. Then, the prompt information is sent to the large language model of the generative model 203. The large language model generates the SQL statement corresponding to the input data based on the prompt information, and then uses the SQL statement to query the database 300 to obtain the query results. Based on the query results, a response text is generated and fed back to the client 100. If the user's input data has the intent of data analysis, the generative model 203 can send the query results to the analysis model 204. The analysis model 204 generates analysis results based on the query results, and generates a response text based on the analysis results and feeds it back to the client 100.

[0086] Optionally, the graph model 201 includes multiple nodes, each node representing an indicator. Each node can establish a mapping relationship with a physical table in the database and fields within that physical table. This mapping relationship includes a semantic mapping relationship, meaning that if the semantics represented by the first indicator are the same as the semantics of the first field, then a semantic mapping relationship can be established between the first indicator and the first field. This mapping relationship also includes a computational mapping relationship, meaning that if a second indicator is obtained from multiple second fields through a series of calculations, then a computational mapping relationship can be established between the second indicator and the multiple second fields.

[0087] In graph model 201, edges can also exist between multiple nodes. These edges indicate the relationships between nodes. These relationships include semantic relationships, where the semantics represented by the third indicator are the same as those represented by the fourth indicator, and the node corresponding to the third indicator can be associated with the node corresponding to the fourth indicator through an edge. Relationships also include computational relationships, where the fifth indicator is calculated based on the sixth and seventh indicators, and the node corresponding to the fifth indicator can be associated with the nodes corresponding to the sixth and seventh indicators through an edge.

[0088] Thus, when the system receives user input data, if the intent of the input data is to read the first indicator, the reading logic for reading the first field can be obtained based on the mapping relationship between the first indicator and the first field. The translation model in generation model 203 can then output an SQL statement based on this reading logic. If the intent of the input data is to read the second indicator, the corresponding calculation logic can be obtained based on the mapping relationship between the second indicator and multiple second fields. The translation model can then output an SQL statement based on this calculation logic. Similarly, the third and fifth indicators mentioned above can be read in a similar way; examples are not provided here.

[0089] Among them, the translation model in the generation model 203 is used to generate SQL statements based on the query logic. The query logic includes the processing flow and the reading methods of multiple fields and tables involved in the processing flow. Based on the query logic and combined with SQL syntax knowledge, the translation model can generate SQL statements corresponding to the input data.

[0090] It should be understood that even if the fields in the physical table are inconsistent with the metrics requested in the input data, the graph model 201 stores multiple semantically similar metrics. By matching the graph model 201, the corresponding fields for the metrics can be found, and the read logic for reading that field can be generated, thus generating an SQL statement. For example, if a user requests to read the "profit" metric, and the physical field is only "net income," but the graph model 201 stores the mapping relationship between the "profit" metric and the "net income" field, the read logic for the "profit" metric can be determined based on the graph model 201, and the translation model can output an SQL statement based on this read logic.

[0091] It should be understood that even if the requested indicator is not present in the physical table, the graph model 201 stores the calculation logic for some indicators. By matching the graph model 201, multiple fields corresponding to the indicator and the calculation logic between these fields can be found, thus generating the calculation logic for reading the indicator and ultimately generating an SQL statement. For example, if a user requests to read the "profit" indicator, and the physical fields are only "sales revenue" and "cost," the graph model 201 stores a mapping relationship between the "profit" indicator and the "sales revenue" and "cost" fields, and this mapping relationship includes calculation logic. Based on this, the calculation logic for the "profit" indicator can be determined, and the generation model 203 can output an SQL statement based on this calculation logic.

[0092] Optionally, the vector library 202 includes vectors derived from the descriptive text of the indicators and the calculation formulas. For example, the descriptive text may include: "Profit is the difference between sales revenue and cost," and the calculation formula may include: "Profit = Sales Revenue - Cost."

[0093] Furthermore, the descriptive text includes the semantic interpretation of the indicator under different expressions, as well as the textual description of the calculation logic under different expressions. The calculation formula includes the calculation formula of the indicator under different calculation methods. An indicator may only include descriptive text, or an indicator may only include formula, or an indicator may include both descriptive text and formula, or an indicator may include descriptive text in multiple different expressions and formulas in multiple different calculation methods. For example, the indicator of profit may include descriptive text 1: "Profit is the difference between sales revenue and cost," descriptive text 2: "Gross profit indicates the surplus of a company after selling goods or providing services, after deducting direct costs," and descriptive text 3: "Net profit is the company's final earnings, showing the net profit after deducting all expenses." It may also include calculation formula 1: "Profit = Sales Revenue - Cost," and calculation formula 2: "Operating Profit = Gross Profit - Operating Expenses (including sales expenses, administrative expenses, R&D expenses, etc.)." It should be understood that the above examples are for illustration only and this application does not impose specific limitations.

[0094] Thus, when the system receives user input data, if the intention of the input data is to read the first indicator, but the first indicator does not exist in the graph model 201, the vector library can be used to match the first indicator. The vector library 202 stores a large amount of indicator calculation logic. The first indicator is matched with the vector library 202 to obtain the description text and / or formula corresponding to the first indicator. Based on the description text and / or formula, the prompt information of the first indicator is obtained, and then the SQL statement is generated based on the prompt information.

[0095] Specifically, if the parameters in the prompt information obtained by the vector library 202 can be mapped to the physical fields in the database 300, for example, if the parameter name included in the prompt information is the same as the physical field name, or if the physical field mapped to the parameter in the prompt information can be obtained by combining the graph model 201, or if the physical field mapped to the parameter can be obtained by combining the metadata of the physical table, then a query logic containing physical table information can be obtained based on the prompt information, and this query logic can be sent to the translation model to output the SQL statement.

[0096] If the parameters in the prompt message cannot be mapped to the physical fields in database 300, the translation model in generative model 203 cannot be used. In this case, the prompt message can be input into a large language model (LLM) to generate the corresponding SQL statement. This large language model can be pre-trained based on database 300, for example, by injecting the structural information of database 300 as knowledge into the large language model, enabling the large language model to generate SQL statements for database 300.

[0097] It should be understood that Vector Library 202 can store a large number of descriptive texts and formulas for indicators in various fields. In this way, no matter what the input data is, even if the fields in the physical table are inconsistent with the indicators requested in the input data, or even if the indicators requested in the input data do not exist in the physical table, Vector Library 202 can be used to find the descriptive texts and formulas corresponding to the indicators in the input data. The corresponding descriptive texts and formulas can be found through Vector Library 202 to guide the large language model or translation model to generate the SQL statements corresponding to the input data, thus meeting the user's needs.

[0098] It should be understood that the graph model 201 contains a large number of metrics that are mapped to physical fields in the database. This mapping of numerous metrics consumes system resources. If some less frequently used metrics are also mapped in the graph model 201, it will cause the graph model 201 to consume significant storage resources, and the latency of matching the graph model 201 will also increase, affecting SQL generation efficiency. Therefore, some less frequently used metrics can be stored in the vector library 202. The vector library 202 does not need to store the complete mapping relationships; it only needs to store the formulas or descriptive text of the metrics. This allows the vector library 202 to more efficiently manage and store the abstract representations of a large number of metrics. In this way, frequently used metrics can be directly mapped from the graph model, while less frequently used metrics can be indirectly mapped through the vector library, thereby reducing the overall computational and storage burden.

[0099] Optionally, the translation model in generation model 203 generates the SQL statement corresponding to the input data based on the query logic containing physical table information. The large language model in generation model 203 generates the SQL statement for the input data based on the prompt information that does not contain physical table information, leveraging the processing capabilities of the large language model. The translation model's main function is to generate the SQL statement based on the multiple physical table fields of the input data, the calculation logic between the fields, and the user's intent in the input data. The large language model's main function is to use the prompt information generated by vector library 202 as prompt words, and generate the SQL statement corresponding to the input data based on the large language model's generation capabilities. Of course, the large language model is a model pre-trained on database 300, possessing the ability to generate SQL statements that database 300 can use.

[0100] Furthermore, user input data may or may not include analytical intent, resulting in different analytical content and results. If user input data does not include analytical intent, for example, if the user input data includes the natural language text "Please give me this year's profit statement," then the user's intent is only a query intent, not an analytical intent. If the user input data includes the natural language text "Please give me this year's profit statement and predict next year's profit," then the user's intent includes both a query intent and an analytical intent. If analytical intent exists, the generative model generates an SQL statement, uses an SLQ statement to perform a query in database 300, obtains the query results, generates a response text based on the query results, and sends it to client 100. If user input data includes analytical intent, the query results can be sent to analytical model 204 for processing.

[0101] Optionally, the analysis model 204 is used to generate analysis results based on the query results and user input data, and then generate a response text based on the analysis results. Of course, if the input data does not include analytical intent, then a response text can be generated based on the query results. Specifically, the data query system 200 may include one or more analysis models 204, each of which can be used to handle a type of business-related analysis task. Analysis tasks may include descriptive data analysis tasks, mainly used to analyze the characteristics, trends, and overall situation of data, such as sales data analysis and user behavior analysis. Analysis tasks may also include diagnostic data analysis tasks, mainly used to explore the causes and impacts of data generation, such as product quality analysis and customer churn analysis. Analysis tasks may also include predictive data analysis tasks, mainly used to use historical data and models to predict future trends or outcomes, such as sales forecast analysis and stock price forecast analysis. The analysis task may also include guided data analysis tasks, which can not only predict future trends or results, but also recommend action plans that can be taken, such as supply chain optimization analysis, marketing strategy optimization analysis, etc. The above examples are for illustration purposes. This application does not limit the specific types or number of analysis models 204. They can be flexibly set according to the actual business scenario. This application does not make specific limitations.

[0102] It should be understood that by configuring the analysis model 204, the user's input data can be more flexible, including not only data query input data, but also data analysis input data, to meet the user's diverse needs and improve the user experience.

[0103] In one possible implementation, the data query system 200 may include only the graph model 201, or the data query system 200 may include only the vector library 202, or, as shown in Figure 1, the data query system 200 includes both the graph model 201 and the vector library 202. This application does not impose any specific limitations.

[0104] In summary, the data query system provided in this application, upon receiving user input data, first determines the indicator that the input data needs to retrieve. If the indicator exists in the graph model 201, the system determines the query logic corresponding to the input data based on the mapping relationship between the indicator and table data in the graph model 201, and generates the corresponding SQL statement based on the query logic. If the indicator does not exist in the graph model 201, the system can determine the corresponding prompt information through the vector library 202, and input the prompt information into the large language model to obtain the SQL statement. This ensures that even if the expression of the input data differs from the field expression in the database, or if the indicator requested by the input data does not exist in the database and requires a series of calculations using some fields in the database, the corresponding calculation logic can be obtained through the graph model 201 or the vector library 202, thereby obtaining the corresponding SQL statement for the input data. This allows users to flexibly and without restrictions input natural language text to complete queries, reducing the error rate of natural language queries and meeting user query needs.

[0105] The data query system provided by this application has been described in detail above. The data query method provided by this application will now be explained in conjunction with Figures 3-9. This method can be applied to the data query system shown in Figures 1 and 2. The data query method includes a configuration phase and an application phase. Figures 3-7 describe the configuration phase in detail, and Figures 8-9 describe the application phase in detail.

[0106] Figure 3 is a flowchart illustrating the steps of a data query method provided in this application during the configuration phase. As shown in Figure 3, the method may include the following steps:

[0107] S310: Client 100 sends a graph model configuration request to data query system 200.

[0108] In one embodiment, a graph model configuration request is used to configure a graph model 201, which includes multiple nodes, each node representing an indicator, and each node can establish a mapping relationship with table data in a database. This mapping relationship includes a semantic mapping relationship, meaning that if the semantics represented by a first indicator are the same as the semantics of a first field, then a semantic mapping relationship can be established between the first indicator and the first field. This mapping relationship also includes a computational mapping relationship, meaning that if a second indicator is obtained from multiple second fields through a series of calculations, then a computational mapping relationship can be established between the second indicator and the multiple second fields.

[0109] It should be noted that the graph model 201 can be implemented by user configuration, or by system recommendation, or it can be partially user-configured and partially system-recommended. This application does not impose any specific limitations.

[0110] In one embodiment, the graph model 201 may include a metadata layer and a semantic layer. The metadata layer is used to record a first mapping relationship between metadata and table data, and the semantic layer is used to record a second mapping relationship between each node (metric) and metadata. The graph model configuration request may include a configuration request for the metadata layer to configure the first mapping relationship between metadata and table data; the graph model configuration request may also include a configuration request for the semantic layer to configure the second mapping relationship between metrics and metadata.

[0111] Optionally, the metadata in the metadata layer describes table data, which is data within database 300. This metadata may include table structure information and address information. The table structure information may include one or more of the following: database name, table name, and field names. A single table may contain multiple fields, therefore, one table may correspond to multiple metadata entries. For example, if table X has a storage address of Y, and table X includes multiple fields such as time, region, and sales revenue, then metadata A may include the field "time" and storage address Y; metadata B may include the field "region" and storage address Y; and metadata C may include the field "sales revenue" and storage address Y. It should be understood that the above examples are for illustrative purposes only and are not specifically limited in this application. Metadata may also include more information, such as field data types, field lengths, primary keys, foreign keys, indexes, table types, and table version information. The specific content of the metadata can be flexibly set according to actual business needs, and this application does not impose specific limitations.

[0112] In specific implementation, the metadata and the first mapping relationship in the metadata layer can be automatically generated by the data query system 200 based on the table data in the database 300. The data query system 200 can obtain the metadata of the table data through the metadata query function, and then establish the first mapping relationship between the metadata and the table data. Specifically, relational databases can use the metadata query function to obtain metadata information such as the table structure, column names, data types, and constraints. Other data storage and management platforms also provide metadata services, and the metadata of table data can also be obtained by querying metadata. Some data integration tools or data quality tools also provide functions for analyzing metadata, scanning data sources to obtain reports on the metadata information of table data such as columns, data types, and data formats. The metadata of table data can also be obtained through other methods, which are not specifically limited in this application.

[0113] In a specific implementation, the metadata and the first mapping relationship in the metadata layer can also be generated based on the configuration request of the metadata layer input by the user. The configuration request of the metadata layer may include the first mapping relationship between the target metadata and the target table data. Based on the configuration request, the data query system 200 can create the corresponding first mapping relationship and update the metadata layer.

[0114] It should be understood that by establishing the first mapping relationship between table data and metadata through the metadata layer, the graph model 201 can be built based on metadata rather than table data, thereby decoupling the physical table from the graph model 201. If the physical table data changes, the graph model 201 can adapt to new data structures, field changes, or other types of changes by adjusting the metadata, without having to redesign or modify the graph model 201. The existence of the metadata layer can improve the flexibility and adaptability of the graph model 201 and reduce maintenance costs.

[0115] Optionally, the metrics in the semantic layer may include metrics with the same semantics as the metadata. The node corresponding to this metric establishes a second mapping relationship with the metadata. This second mapping relationship can be a semantic mapping relationship, indicating that the two have the same semantics. The node's label is the metric name. This metric can have the same semantics as a field in the metadata, a table name in the metadata, or a database name in the metadata. It should be noted that semantic similarity here not only means that the metric name and metadata use the same characters (e.g., the metric is "profit" and the metadata field is also "profit"), but also that although the metric name and metadata use different characters, the characters express the same semantics (e.g., the metric is "profit" and the metadata field is "net income"). Furthermore, a metric can establish mapping relationships with multiple metadata fields. For example, the "profit" metric can establish a second mapping relationship with metadata fields such as "profit," "net income," and "profit."

[0116] Optionally, the metrics in the semantic layer may include the results calculated from multiple fields. The node corresponding to this metric establishes a second mapping relationship with multiple metadata entries. This second mapping relationship can be a computational mapping relationship, indicating that there is computational logic between the two. The metadata here generally includes the metadata of the fields. For example, a node labeled "Net Sales Revenue for the Same Period Last Year" may have metadata associated with it including fields such as "Total Sales Revenue," "Sales Cost," and "Sales Expenses." This metadata participates in the calculation of net sales revenue for the same period. It should be understood that by mapping the metrics calculated from multiple fields to table data in advance, if a user queries commonly used metrics, they can quickly determine the calculation logic of the metric and the relevant table data through a 201 matching graph model, thereby improving SQL generation efficiency and ultimately query efficiency.

[0117] Optionally, the metrics in the semantic layer may include the results of calculations of multiple other metrics. The node corresponding to the metric establishes a third mapping relationship with multiple other nodes. This third mapping relationship may be a calculation mapping relationship. The multiple other nodes may include the nodes that have the same semantics as the metadata, or nodes that are calculated from the multiple fields mentioned above. This application does not make any specific limitations.

[0118] For example, if profit = sales revenue - cost, then the "profit" metric can be mapped to the "sales revenue" and "cost" metrics. Specifically, the "sales revenue" metric can be mapped to the "sales" field, and the "cost" metric can be mapped to the "costs" field. Alternatively, the "cost" metric can be mapped to the "material cost" and "labor cost" fields, with the calculation logic being cost = material cost + labor cost. These examples are for illustrative purposes only and are not intended to impose specific limitations.

[0119] It should be understood that the indicators in the semantic layer may also include dimensional indicators, such as year, month, quarter, week, etc.; they may also include entity indicators, such as company, customer, partner, subsidiary, contract, logistics information, etc., and may include other types of indicators to facilitate the establishment of some calculation mapping relationships. For example, the indicator of monthly revenue can establish a calculation mapping relationship with the indicator "revenue" and the dimension "month". For example, the annual revenue of Company A can establish a mapping relationship with the entity "Company A" and the indicator "annual revenue". The above examples are for illustration only and are not intended to be specific limitations in this application.

[0120] Optionally, the labels of each node may include one or more attributes. Each attribute can describe the semantic representation of the node from different dimensions. For example, the labels of a node may include the following attributes: field name, data type, whether it is a metric field, etc. For example, the labels of node A include label 1: basketball player and label 2: programmer. Label 1 includes the following attributes: team, position, average points per game, etc., and label 2 includes the following attributes: company, job level, years of service, etc. The above examples are for illustration only and are not specifically limited in this application.

[0121] It should be understood that multi-attribute node tags can make the semantic representation of metadata richer and more accurate. When querying data based on the semantic layer, different attributes can be used to filter, sort and search nodes. In this way, no matter what the user's input data is, even if no indicator is found that directly matches the input data, the node that matches it can be found based on the attributes of the node corresponding to the indicator. This results in a more accurate query logic that matches the input data, and the SQL statement generated based on this will also be more accurate.

[0122] Optionally, edges can exist between nodes, and nodes with relationships can be connected by edges. These relationships can include semantic similarity, meaning that nodes with the same semantics can be connected by edges. These relationships can also include computational associations, meaning that nodes with computational mapping relationships can be connected by edges. These relationships can also include other types such as subordination and dependency, which are not specifically limited in this application.

[0123] In the specific implementation, each edge includes an edge type, and different data associations correspond to different edge types. For example, the primary key dependency edge type connects two nodes where the primary key in one table corresponds to the foreign key in another table; the ordinary dependency edge type indicates that a field in one table depends on a field in another table; and the foreign key mapping edge type indicates that a foreign key in one table corresponds to the primary key in another table. Edge types are used for illustration; the edges between nodes in the semantic layer can include many more types, which will not be listed here.

[0124] Furthermore, an edge can include more information, such as its direction, attributes, and descriptive information. The direction of an edge can include the starting node and the ending node, the attributes can be the strength of the relationship, and the descriptive information can be some notes or descriptions of the edge. The above examples are for illustration only and are not specifically limited in this application.

[0125] It should be understood that by expressing the relationship between different nodes through different types of edges, the data association between table data can also be displayed in the semantic layer through the edges between nodes. In this way, no matter what the user's input data is, even if no indicator is found that directly matches the input data, an indicator that matches it can be found based on the edge relationship, thereby obtaining a more accurate query logic that matches the input data. The SQL statement generated based on this will also be more accurate.

[0126] Optionally, the metrics and mapping relationships in the semantic layer can be automatically generated by the system. If the metric is a semantic representation of metadata, the data query system 200 can use a semantic recognition model to identify the semantic information of the fields contained in the metadata, generate node labels based on the semantic information, and establish a semantic mapping relationship between the metadata and the nodes. If the metric is the calculation result of multiple fields, or the calculation result of multiple metrics, the establishment and mapping of the corresponding nodes for this type of metric can be achieved by importing metric data. This metric data may include the metric's calculation formula or calculation rules. The semantic recognition model identifies the metric's calculation logic, determines the metadata associated with the metric based on the calculation logic, and creates a second mapping relationship between the metric and the metadata. Alternatively, based on the calculation logic, other metrics associated with the metric can be determined, and a third mapping relationship between the metric and other metrics can be created.

[0127] In specific implementations, the aforementioned semantic recognition model can be a machine learning model, including but not limited to word embedding models, recurrent neural networks (RNNs), long short-term memory networks (LSTMs), convolutional neural networks (CNNs), pre-trained language models, etc. Among them, word embedding models can be word-to-vector (Word2Vec) models, global vectors for word representation (GloVe) models, etc., and pre-trained language models can be bidirectional encoder representations from transformers (BERT) models, generative pre-trained transformer (GPT) models, etc. The above examples are for illustration purposes only, and this application does not limit them.

[0128] Optionally, the metrics and mapping relationships in the semantic layer can be generated based on a user-input configuration request for the semantic layer. Specifically, the semantic layer configuration request may include target metric information requested by the user, and a second mapping relationship between the target metric and target metadata, or a third mapping relationship between the target metric and other metrics. The data query system 200 can create nodes corresponding to the target metric in the semantic layer and establish corresponding second or third mapping relationships based on this semantic layer configuration request.

[0129] Similarly, the edges between each node in the semantic layer can be automatically generated by the data query system 200 in conjunction with edge design rules, or they can be generated based on user-input configuration information; this application does not impose specific limitations. Optionally, edge design rules may include primary key dependency relationships, ordinary dependency relationships, and field value dependency relationships, where a primary key dependency relationship refers to a primary key in one table corresponding to a foreign key in another table; an ordinary dependency relationship refers to a field in one table depending on a field in another table; and a field value dependency relationship refers to a field in one table belonging to a field in another table. It should be understood that edge design rules may include more content, which can be determined according to actual business needs; this application does not impose specific limitations.

[0130] It should be understood that by creating some commonly used indicators at the semantic layer and establishing a mapping relationship between these commonly used indicators and metadata, or between indicators, the user's input data can obtain the query logic in the input data through the matching graph model 201. This query logic includes table data and calculation logic, and can generate SQL statements through simple translation. This not only improves query efficiency but also improves the accuracy of SQL statements and enhances the user experience.

[0131] To enable a better understanding of the graph model 201, Figure 4 is an example diagram of a graph model provided by this application. As shown in Figure 4, the graph model may include a metadata layer and a semantic layer. The metadata layer includes multiple metadata nodes, each of which can establish a first mapping relationship with table data in the database 300. The semantic layer includes multiple indicator nodes, some of which can establish a second mapping relationship with the metadata nodes in the metadata layer, and some of which can establish a third mapping relationship with other indicator nodes.

[0132] Specifically, at the metadata layer, the system can create multiple metadata nodes based on the table data's metadata, establishing the initial mapping relationship between the metadata nodes and the table data. Alternatively, it can create corresponding metadata nodes and initial mapping relationships based on user-sent metadata layer configuration requests. For details, please refer to the preceding content; these will not be repeated here. For example, as shown in Figure 4, the system establishes the initial mapping relationship between metadata "ydt" and fields in the table, the initial mapping relationship between metadata "hst" and fields in the table, and the initial mapping relationship between metadata "target" and fields in the table, etc. See Figure 4 for details; these will not be elaborated upon here.

[0133] Specifically, at the semantic layer, the system can create multiple indicator nodes based on the semantic recognition model and establish a second mapping relationship between the indicator nodes and the metadata. Alternatively, it can create corresponding indicator nodes and second mapping relationships based on the semantic layer configuration requests sent by the user. For details, please refer to the preceding content; these will not be repeated here. For example, as shown in Figure 4, a second mapping relationship is established between the "time" node and the metadata "time," and a second mapping relationship is established between the "target threshold" node and the metadata "target," etc. For details, please refer to the description in Figure 4; these will not be elaborated upon here.

[0134] Furthermore, at the semantic layer, the system can create multiple indicator nodes based on the semantic recognition model and establish a third mapping relationship between these indicator nodes. Alternatively, it can create corresponding indicator nodes and third mapping relationships based on the semantic layer configuration requests sent by the user. For details, please refer to the preceding content; it will not be repeated here. For example, the "Analysis Indicator A" node can establish a third mapping relationship with the "Net Sales Revenue Year-on-Year" node and the "Target Threshold" node; similarly, the "Net Sales Revenue Year-on-Year" node can establish a third mapping relationship with the "Current Year Net Sales Revenue" node and the "Last Year Net Sales Revenue" node.

[0135] It should be noted that each indicator node can also establish a second mapping relationship with the metadata, and simultaneously establish a third mapping relationship with other indicators. For example, the indicator node "Net Sales Revenue This Year" establishes a second mapping relationship with the metadata node "ydt", and simultaneously establishes a third mapping relationship with the "Time" dimension node and the "Subsidiary A" entity node, indicating that this indicator node represents the net sales revenue over one year. Similarly, the indicator node "Net Sales Revenue Last Year" establishes a second mapping relationship with the metadata node "hst", and simultaneously establishes a third mapping relationship with the "Time" dimension node and the "Subsidiary A" entity node.

[0136] Understandably, if a user requests to query analysis indicator A, based on the graph model 201 shown in Figure 4, the "analysis indicator A" node can be matched. Then, based on the third mapping relationship, the second mapping relationship, and the first mapping relationship associated with this node, the query logic for this indicator is determined. This query logic includes the table data information involved in the calculation, as well as the calculation logic. Based on this query logic, the corresponding SQL statement can be obtained.

[0137] It should be understood that the graph model 201 provided in this application, through multi-level mapping relationships, allows the actual indicators to be decoupled from the underlying table data. When the underlying data changes, it can be adaptively adjusted based on the multi-level mapping relationships without requiring users to modify the indicator configuration. This makes the graph model 201 highly flexible and adaptable. Furthermore, the data retrieval and processing logic can be clearly displayed through the graph model 201, and indicator creation can be more flexible. No matter how complex the professional query logic is, the corresponding indicators can be built through multi-level mapping relationships to meet the user's various usage needs and improve the user experience.

[0138] As can be seen from the foregoing, the graph model 201 can be a model that is automatically configured by the system based on the table data, or a model that is configured according to the user's configuration request. Alternatively, some indicators in the graph model may be pre-configured and some may be configured by the user. This application does not make any specific limitations. If the user uses the model pre-configured by the system and does not need to customize the graph model, then step S310 can be omitted.

[0139] S320: Data Query System 200 is based on a table data configuration graph model.

[0140] In specific implementation, if a user sends a graph model configuration request, the data query system 200 can create a metadata layer and a semantic layer in the graph model 201 based on the graph model configuration request, establishing a mapping relationship between indicators and table data. If the user does not send a graph model configuration request, the data query system 200 can also create a metadata layer based on the table data, establish a semantic layer based on the semantic recognition model, and establish a mapping relationship between indicators and table data. For details, please refer to the relevant descriptions in S310 and the embodiment in Figure 4, which will not be repeated here.

[0141] S330: Client 100 sends a vector library configuration request to data query system 200.

[0142] In one embodiment, a vector library configuration request is used to configure a vector library 202. This vector library includes multiple vectors, each of which can be obtained by vectorizing a calculation formula for an indicator or by vectorizing descriptive text of an indicator. The vector library configuration request may include descriptive text or calculation formulas requested by the user to be stored in the vector library 202. After receiving the vector library configuration request, the system can vectorize the calculation formulas or descriptive text carried in the request according to vectorization rules, obtain the corresponding vectors, and store them in the vector library 202.

[0143] Optionally, the vectors in the vector library 202 include user-configured vectors. After the user imports a large number of indicator calculation formulas or a large number of indicator description texts by sending a vector library configuration request, the data query system 200 vectorizes these calculation formulas and description texts to obtain multiple vectors, which are then stored in the vector library 202.

[0144] Optionally, the vectors in vector library 202 include vectors pre-configured by the system. The system can pre-connect to the user's business platform, indicator platform, dimension platform, or other knowledge base, and store the descriptive text and calculation formulas of a large number of commonly used indicators in vector library 202 after vectorization. The algorithm used for vectorization can be a commonly used algorithm in the industry, and this application does not impose specific limitations.

[0145] It should be noted that if the user does not require configuring a vector library, that is, if the user chooses to use the system's pre-configured vector library 202, then step S330 can be omitted.

[0146] In specific implementation, each indicator in vector library 202 can be described by at least one descriptive text, or by at least one calculation formula, or by both at least one descriptive text and at least one calculation formula; this application does not impose specific limitations. The indicators in vector library 202 can be indicators not present in graph model 201, or indicators present in graph model 201; this application does not impose specific limitations.

[0147] It should be noted that the description text may include the calculation logic of the indicator, as well as the definition of the indicator, synonyms of the indicator, background knowledge of the indicator, etc. The specific details can be determined according to the actual business scenario, and this application does not impose any specific limitations.

[0148] For example, Figure 5 is an example diagram of a vector library provided in this application. Figure 5 exemplarily shows multiple calculation formulas and descriptive texts for the indicator "gross profit margin". It should be understood that Figure 5 directly displays the calculation formulas and descriptive texts for ease of understanding. In the specific implementation, the vector library 202 stores vectors. These calculation formulas and descriptive texts can be vectorized to obtain corresponding vectors before being stored in the vector library.

[0149] In the example shown in Figure 5, "gross profit margin" has multiple descriptive texts and calculation formulas. These descriptive texts and calculation formulas contain various expressions and synonyms to adapt to different query and application scenarios, enabling the query system to more accurately match and retrieve the indicators corresponding to the input data, and thus generate SQL statements more accurately. The example of vector library 202 in Figure 5 is for illustrative purposes only and is not specifically limited in this application.

[0150] It should be understood that Vector Library 202 stores a large number of vectors obtained by vectorizing descriptive text and calculation formulas. Therefore, Vector Library 202 can be created quickly, and each vector can be flexibly expressed through descriptive text and calculation formulas. Theoretically, it can cover various scenarios. No matter what the user's input data is, the descriptive text or calculation formula corresponding to the input data can be determined through the vectors in Vector Library 202, providing guidance for the generation of SQL statements and meeting the user's various usage needs.

[0151] S340: Data Query System 200 Configuration Vector Library.

[0152] Specifically, if the user needs to customize the vectors in the vector library, then client 100 executes S330, and data query system 200 updates the vector library 202 according to the vector library configuration request. If the user does not need to customize the vectors in the vector library, then data query system 200 can combine some commonly used and unused knowledge bases to complete the configuration of the vector library, vectorizing the data from the relevant knowledge bases of commonly used and unused indicators and importing them into the vector library. For details, please refer to the aforementioned S330 and the relevant description in Figure 5, which will not be repeated here.

[0153] In specific implementation, for the descriptive text, after the data query system 200 obtains the descriptive text of the indicator uploaded by the user, or obtains the descriptive text of the indicator from the knowledge base, it can first perform tokenization on the descriptive text, dividing the text into multiple words. Then, through word embedding models, each word can be mapped to a vector in a high-dimensional space to obtain the word embedding vector of each word. Then, a convergence method (such as average pooling or weighted pooling) is used to combine the word embedding vectors of all words into a vector representation of the entire descriptive text. Alternatively, the descriptive text can be directly input into a pre-trained language model, such as the BERT model, and then the vector output by the hidden layer of the model can be used as the semantic vector of the input data. The hidden layer of the BERT model is the last layer of the encoder in the transformer model. Of course, other methods can also be used to obtain the vector of the descriptive text, and this application does not impose specific limitations.

[0154] In specific implementation, for the calculation formula, after the data query system 200 obtains the calculation formula of the indicator uploaded by the user, or obtains the calculation formula of the indicator from the knowledge base, it can first obtain the parsing result of the calculation formula through the mathematical expression parser. This parsing result includes multiple calculation steps and the calculation order corresponding to each calculation step. The calculation order corresponding to each calculation step can be expressed by a tree structure or Reverse Polish notation. Then, each variable and calculation symbol in the parsing result is mapped into a vector representation; this step can also be called symbol embedding. Then, the parsing result and the vector representation are fused to determine the vector representation of each calculation step. Then, the vector representations of multiple calculation steps are connected according to each calculation order to obtain the vector representation of the entire calculation formula. Of course, other methods can also be used to obtain the vector corresponding to the calculation formula; this application does not impose specific limitations.

[0155] Optionally, the data query system 200 obtains a large number of descriptive texts and calculation formulas for indicators. After vectorizing these texts as described above, it uses a clustering algorithm to group similar descriptive texts and calculation formulas into a single category, obtaining the topic for each category. The clustering algorithm may include K-means or hierarchical clustering methods, etc., and this application does not impose specific limitations. Then, a vector index is created, connecting the vectors of descriptive texts or calculation formulas within the same category to the corresponding topic for that category. In this way, the data query system 200 obtains input data, determines the indicator to be queried based on the input data, vectorizes the indicator to be queried, and uses the vector index to find the topic most similar to the indicator to be queried. Then, under that topic, it finds the descriptive text and calculation formula closest to the indicator to be queried. Specifically, a similarity measurement algorithm can be used to find the most similar topic, the most similar descriptive text, or the most similar calculation formula, such as cosine similarity, Euclidean distance, etc., and this application does not impose specific limitations.

[0156] Optionally, after the data query system 200 creates the vector library, users can upload new descriptive text or calculation formulas, along with corresponding topic names, according to their needs. The data query system 200 can then vectorize the new descriptive text or calculation formulas using the methods described above, add them to the corresponding topic, and update the vector index. If the user-entered topic name is a new topic, a corresponding new topic can be created in the vector index, and the vector index can be updated. Users can also modify existing topics, descriptive texts, or calculation formulas in the vector library according to their needs. The vector library can also have version control and rollback functions to restore previous versions in case of accidental or unintentional modifications. The vector library can also have access control functions to ensure that only authorized users can perform modification and deletion operations, avoiding data security issues.

[0157] It should be understood that after configuring the vector library 202, during the data query phase, if the user's requested query indicator is determined based on the user's input data, a search is first performed in the graph model 201. However, if no matching indicator node is found, the vector library 202 can be used to retrieve the descriptive text and calculation formula of the query indicator. Then, the descriptive text and calculation formula are sent to the large language model as prompts to provide guidance for the large language model, enabling it to generate accurate SQL statements for the input data.

[0158] In specific implementation, a prompt can be a piece of text, a set of instructions, a question, or other forms of information. A prompt generated based on descriptive text and / or calculation formulas includes one or more of the following: descriptive text, calculation expiration, data processing instructions, contextual explanations, and user intent. The specific form of the prompt can be flexibly designed according to the actual business scenario. The form of the prompt can be diverse, such as a single-sentence prompt, a multi-sentence prompt, a template-based prompt, a question-and-answer format prompt, etc. It can also include more forms, which are not specifically limited in this application.

[0159] For example, if the input data is: "Give me this year's gross profit margin", and the query indicator is "gross profit margin", the vector library will provide description text A: "Gross profit margin is the ratio of gross profit obtained from sales to total sales revenue", and the calculation formula B: "Gross profit margin = ((sales revenue - cost of sales) / sales revenue) × 100%". Several possible prompts are given below as examples.

[0160] Optionally, the prompt for a single sentence could be: "Check this year's gross profit margin. Gross profit margin is the ratio of gross profit from sales to total sales revenue. The formula is Gross Profit Margin = ((Sales Revenue - Cost of Goods Sold) / Sales Revenue) × 100%".

[0161] Optionally, the multi-sentence prompt could be: "Refer to this year's sales revenue and cost of sales statements to calculate the gross profit margin. The gross profit margin is defined as the ratio of gross profit earned from sales to total sales revenue. The formula for calculating the gross profit margin is: Gross Profit Margin = ((Sales Revenue - Cost of Sales) / Sales Revenue) × 100%".

[0162] Alternatively, the template-style prompt can be:

[0163] [Description Text] Gross profit margin is the ratio of gross profit from sales to total sales revenue.

[0164]

Calculation Formula

[0165]

Operation

[0166] Alternatively, a question-and-answer format prompt can be:

[0167] [Question] Please provide the gross profit margin for this year's sales.

[0168] [Answer] Gross profit margin is the ratio of gross profit obtained from sales to total sales revenue. The formula is Gross Profit Margin = ((Sales Revenue - Cost of Goods Sold) / Sales Revenue) × 100%.

[0169] It should be understood that the above examples provide some possible prompts, the forms of which are for illustrative purposes only and are not specifically limited in this application.

[0170] It should be noted that the graph model 201 and the vector library 202 can be pre-configured by the system, or configured by the user, or a combination of both. If the user does not need to configure the graph model 201 and the vector library 202, then S310 and S330 can be omitted.

[0171] As mentioned above, graph model 201 stores a large number of mapping relationships between indicators and table data, while vector library 202 stores a large number of descriptive texts and calculation formulas for indicators. Compared to graph model 202, graph model 201 has a more complex configuration process, requiring configuration of the metadata and semantic layers, as well as mapping relationships. It also consumes more storage and computing resources. Vector library 202, on the other hand, has a simpler configuration process, requiring only the import of descriptive text or calculation formulas, and consumes fewer storage and computing resources. However, graph model 201 can obtain the calculation logic of indicators and related table data by matching the graph model during data querying, and can generate corresponding SQL statements based on a simple translation model, resulting in higher query efficiency. In contrast, vector library 202, after obtaining the calculation formulas or descriptive texts corresponding to the indicators in the input data, needs to input them into a large language model and utilize its generation capabilities to obtain SQL statements. This process is less efficient than the matching method of graph model 201.

[0172] In short, both the graph model 201 and the vector library 202 have their own advantages and disadvantages. Therefore, in scenarios where query efficiency is prioritized over query accuracy, the data query system 200 may only include the graph model 201, in which case steps S330 and S340 can be omitted. In scenarios where query efficiency is less important than query accuracy, the data query system 200 may only include the vector library 202, in which case steps S310 and S320 can be omitted. In scenarios where both query efficiency and accuracy are important, the data query system 200 may include both the graph model 201 and the vector library 202. For example, commonly used indicators can establish a mapping relationship between indicators and table data in the graph model 201, while less frequently used indicators can be stored in the vector library 202. This reduces the overall computational and storage burden, while allowing for fast queries of commonly used indicators and accurate queries of less frequently used indicators, meeting various data query needs of users and improving the user experience.

[0173] S350: Data Query System 200 trains translation models and large language models.

[0174] Optionally, the translation model is used to generate SQL statements corresponding to the input data based on the query logic output by the graph model 201. The query logic includes a processing flow and table information involved in the processing flow, with the table information including the methods for reading fields involved in the processing flow. The translation model may include a code template, which integrates the table information and processing flow into the code template to generate the SQL statements corresponding to the input data.

[0175] In practice, the translation model can create a semantic model of the processing flow according to certain modeling specifications (graph schema), then integrate the table information into the semantic model to obtain an instance model, and then translate the corresponding execution script based on the instance model to obtain the SQL statement.

[0176] For example, Figure 6 is an example diagram of the processing logic of a translation model provided in this application. As shown in Figure 6, after obtaining the query logic output by the graph model 201, the translation model can create a semantic model of the processing flow according to the modeling specifications. Figure 6 uses income = quantity × price as an example to calculate the distance of the semantic model. Then, the table information is fused with the semantic model corresponding to the processing flow to generate an instance model containing table information. This model includes the processing flow of specific table information. The income field in Table 1 = the quantity field in Table 1 × the price field in Table 2. Based on this instance model, the corresponding SQL statement can be generated.

[0177] In practice, the translation model can predefine the conversion rules of SQL statements, then use a parser to read and parse the instance model, extract the structure and data, and then convert the structure and data based on the conversion rules to generate the corresponding SQL statement script. It can also be combined with some SQL statement generation tools to complete the above process. This application does not make any additional provisions.

[0178] It should be understood that the translation model generates an instance model based on the query logic, and then generates SQL statements based on the instance model. This allows complex processing flows to be clearly and logically written into the instance model, avoiding errors or omissions caused by complex processing flows and complex table structure information. At the same time, the instance model provides a standardized method for generating SQL statements; many parsers and database design tools can automatically generate SQL code from the instance model, thereby improving development efficiency.

[0179] Optionally, the large language model is used to generate SQL statements corresponding to the input data based on the prompts from the vector library 202. These prompts include descriptive text or calculation formulas for the indicators. This prompt can serve as a prompt for the large language model, guiding its output of the SQL statements.

[0180] In specific implementation, when training the large language model, samples can be created based on the vector library 202. The input data of these samples includes the input data and prompt information, and the labels include the SQL statements corresponding to the input data. A large language model is obtained by training with a large number of samples. This large semantic model may include, but is not limited to, GPT, BERT, Ttransformer, etc., and this application does not make any specific limitations.

[0181] Furthermore, when training a large language model, database structure information can be obtained from Database 300. This information can then be injected into the large language model through knowledge injection. Knowledge injection refers to providing the model with additional information or knowledge, either manually or automatically, during training to help it better understand the task and data. This database structure information includes the semantics of metadata and the physical mapping between metadata and table data. For example, establishing a physical mapping between the metadata semantics "order quantity" and the field "order_count". It should be understood that by establishing a sample set using the database structure information, the model can learn to generate SQL while simultaneously understanding the semantics represented by different fields and tables in Database 300. This allows the trained large language model to generate SQL statements used in Database 300.

[0182] It should be noted that the semantic layer indicator nodes can include computational logic in text form and computational logic in structured form. If the computational logic is in structured form, an SQL statement can be output using a translation model. If the computational logic is in text form, it can also be used as a prompt message and output as an SQL statement through a large language model.

[0183] S360: Data Query System 200 Training and Analysis Model.

[0184] In practical implementation, if the user's input data contains a data analysis intent, the corresponding analysis model can be determined based on that intent. Then, the analysis model is used to obtain the analysis results, and a response text corresponding to the input data is generated based on these results. Therefore, the data query system 200 can train multiple analysis models based on the user's possible analysis intents, with each model corresponding to a specific analysis intent. Each analysis model is used to handle a data analysis task corresponding to a particular analysis intent. Analysis models may include, but are not limited to, business data analysis, tax case analysis, and tax audit case analysis; this application does not impose specific limitations.

[0185] In its implementation, each analysis model comprises multiple processing steps. These steps, arranged in a specific order, form a workflow, allowing the data query system 200 to automatically complete each step and obtain the analysis results by calling the analysis model. Each analysis model can be designed with processing steps and sequences according to the analysis intent, tailored to specific business scenarios.

[0186] For example, Figure 7 is an example diagram of an analysis model provided in this application. This analysis model is a time series prediction algorithm analysis model used to complete data analysis tasks such as time series prediction of indicators and anomaly detection. As shown in Figure 7, the analysis model may include multiple processing stages, each arranged in a certain processing order, and each processing stage may also include multiple processing steps. The following explanation of each processing stage, in conjunction with Figure 7, follows the processing order: The data import stage includes steps such as file upload and dimension parsing. The data exploration stage includes steps such as realizing time series visualization, granularity identification, and calculation of time series stability evaluation indicators. The data preprocessing stage includes steps such as missing value handling and invalid value removal. The anomaly handling stage includes steps such as anomaly detection, anomaly value visualization, and anomaly value processing. The change point handling stage includes steps such as change point detection, change point visualization, change point user specification, and change point slice prediction. The time series clustering stage may include steps such as clustering method selection and time series clustering result visualization. The time series pattern configuration stage includes steps such as model parameter adjustment and model smoothness configuration. The feature engineering stage includes steps such as lag order configuration. The time series model training phase includes steps such as training set configuration, test set configuration, selection of single-time series prediction models, selection of multi-time series prediction models, and automatic hyperparameter optimization. Other model training phases include steps such as training set configuration, test set configuration, selection of neural network methods, and selection of machine learning methods. The model evaluation and selection phase includes steps such as selection of model evaluation metrics, time series cross-validation, visualization of model test set results, selection of model performance ranking methods, and model fusion. The model prediction phase includes steps such as configuring prediction granularity, configuring the number of prediction periods, and visualizing prediction results.

[0187] It should be understood that Figure 7 is an example of an analysis model. Other analysis models can be flexibly configured with each processing step in the analysis model in combination with business scenarios and user analysis intentions. This application will not provide examples of each of them.

[0188] It should be understood that by pre-establishing multiple analytical models, user input data can not only be used to complete data queries through natural language, but also to complete data analysis tasks such as predictive analysis and anomaly analysis through natural language, thereby meeting users' various usage needs and improving the user experience.

[0189] It should be noted that the translation model, large language model, and analysis model can be either pre-set models of the system or user-defined models. If users need to customize the above models, they can send the corresponding configuration request to the data query system 200 through client 100. This will not be elaborated further here.

[0190] It should be noted that the above configuration process mainly describes the configuration of graph model 201, vector library 202, translation model, large language model and analysis model. The data query system 200 may also have training and configuration processes for other models, such as an intent recognition model that determines the user's query intent based on the user's input data. This application does not make specific limitations on these models.

[0191] S370: Data query system 200 returns a configuration success message to client 100.

[0192] It should be understood that after the user receives the configuration success message through the client 100, the user can start using the data query system 200. The data query system 200 can then enter the application phase and prepare to generate the corresponding response text based on the user's input data, combined with the graph model 201, vector library 202, translation model, large language model, and analysis model.

[0193] It should be noted that the data query system 200 can be implemented based on the AutoGen framework, which can include multiple agents. Each agent can be a program or component with specific functions, capable of making decisions and taking actions based on input. Each agent is customizable and has the ability to communicate with each other. The processes described in S310 to S370 can also be understood as the process of configuring multiple agents. The configured agents can communicate with each other, forming the basic logic of a multi-agent collaborative processing strategy. When the system obtains user input data, multiple agents can automatically run and communicate with each other, enabling the data query system 200 to obtain the response text corresponding to the input data based on the multi-agent collaborative processing strategy.

[0194] For example, graph model 201 and vector library 202 can be implemented using agent1 to determine query logic or prompts based on input data. Generation model 203 can be implemented using agent2 to determine the SQL statement based on the query logic or prompts, and then execute the SQL statement to generate query results. Analysis model 204 can be implemented using agent3 to determine whether there is an analytical intent based on the input data; if so, the analysis model is used to obtain the analysis results from the query results. It should be understood that through the AutoGen framework, the various agents can automatically execute tasks, achieving automatic SQL generation, automatic execution, and automatic data analysis.

[0195] The agent comprises a code writer and a code executor. The code writer generates program code based on user input, utilizing a large language model that supports code writing, such as the GPT model, to generate code segments. The code executor executes the generated code segments. Therefore, the large language model used in this application to generate SQL statements based on prompts can be implemented based on this code writer, enabling agent2 to generate SQL statements based on prompts using the code writer, and to execute the SQL statements to generate query results using the code executor.

[0196] It should be noted that the above agent allocation method is an example. Each agent is a customizable program or component that can communicate with each other and has specific functions. Therefore, agents can be flexibly allocated according to business needs. For example, in another example, the graph model 201 and the translation model are implemented through agent1, the vector library 202 and the large language model are implemented through agent2, the analysis model is implemented through agent3, or other combinations. This application does not make specific limitations.

[0197] The steps and flow of the data query method provided in this application during the configuration phase have been described in detail above with reference to Figures 3-7. The steps and flow of the data query method provided in this application during the application phase will be explained below with reference to Figures 8-9.

[0198] Figure 8 is a flowchart illustrating the steps of a data query method provided in this application during the application stage. As shown in Figure 8, the method may include the following steps:

[0199] S801: Client 100 sends input data to data query system 200.

[0200] In specific implementation, the input data includes the user's query data, which includes natural language text used to query the data, such as "I want this year's sales report," "Please give me the sales data of all products in the fourth quarter of last year," "How many interns are there in Department S," etc.; it may also include natural language text used to obtain analysis results, such as "Please predict the sales of the next quarter," "Please check if there are any errors in the sales data of the second quarter," etc.; it may also include multimodal data such as audio, video, images, and sensor data as auxiliary input for data query or data analysis. For example, the input data may include the natural language text "What style of architecture is the building in this picture?" and an image including the building. It should be understood that the above examples are for illustration, and users can flexibly input input data composed of natural language according to business needs. This application provides specific limitations.

[0201] It should be understood that traditional data queries require users to input query statements in database language, such as SQL. Natural language query text, on the other hand, is closer to everyday human language, allowing non-technical users to easily perform data queries and reducing their learning curve. Furthermore, traditional query statements not only require learning the structure of the query language but also memorizing the names of various tables; for example, the name of the balance sheet might be a string that users would need to input when using SQL. Using the method described in this application, users can simply input "I need a balance sheet," allowing them to obtain the corresponding query results directly from the input of the terms, thus improving efficiency.

[0202] Meanwhile, traditional data analysis requires users to use SQL to search for relevant data and then analyze it using analysis tools. This application allows users to directly input data containing analytical intent through the data query system 200, such as "Please give me the sales report for the third quarter and a forecast of the sales for the fourth quarter." The system can then directly return the corresponding response text without requiring users to run analysis tools, thus improving analysis efficiency, reducing user steps, and enhancing the user experience.

[0203] It should be understood that after obtaining the query index corresponding to the user's input data in S801, the data query system 200 can use the multi-agent collaborative processing strategy described above to confirm the data query result. The multi-agent collaborative processing strategy is used to indicate at least one way to achieve data retrieval based on graph models and vector libraries. The specific process of the multi-agent collaborative processing strategy can be shown in S802 to S811 below.

[0204] S802: The data query system 200 determines the intent based on the input data and obtains the query indicators based on the intent.

[0205] Optionally, the data query system 200 can determine the intent of the input data based on an intent recognition model, and then determine the corresponding query metric based on the intent. The intent describes the purpose of the user sending the input data, and may include data query, data analysis, execution of operations, system configuration, etc. The main purpose of intent recognition is to help the system understand the user's intent so that the system can respond and act accordingly. Different intents can correspond to different processing flows. In this embodiment, if the intent of the input data is a query intent or an analysis intent, subsequent steps S803-S811 are executed. If the intent of the input data is another intent such as execution of operations or system configuration, corresponding other operations can be executed; this application does not impose specific limitations.

[0206] It should be noted that each intent can be further subdivided. For example, data query intent can include statistical information query intent, detailed data query intent, summary query intent, etc. The specific intent can be determined according to the actual business scenario, and this application does not make specific limitations.

[0207] In a specific implementation, the aforementioned intent recognition model can be obtained by training the machine learning model with a sample set in advance. The machine learning model can be a support vector machine (SVM), a naive bayes classifier, a recurrent neural network (RNN), a convolutional neural network (CNN), a transformer, etc. This application does not make any specific limitations.

[0208] Optionally, the data query system 200 can use intent combined with an entity recognition model or entity recognition rules to identify keywords or phrases in the input data that are related to data query and data analysis, thereby obtaining the query indicator. This query indicator includes not only the indicator itself but also the related scope; for example, the indicator could be "2022 sales revenue," which includes not only the field but also the query scope. The above examples are for illustrative purposes only and are not intended to impose specific limitations.

[0209] In specific implementation, the aforementioned entity recognition model can be obtained by training a machine learning model using a sample set based on named entity recognition (NER) technology. This entity recognition model can be a BERT model, a BERT-CRF model, etc., and this application does not impose any specific limitations. The aforementioned entity recognition rules can include keyword-based recognition rules, part-of-speech-based recognition rules, etc. Keyword-based recognition rules refer to setting a list of keywords or phrases and identifying entities in the input data by matching the list, thereby obtaining the query indicator. For example, keywords for financial data queries could be "sales revenue," "profit margin," "cost," etc. Part-of-speech-based recognition rules refer to matching specific types of words based on their parts of speech, such as noun phrases, verb phrases, etc. More types of recognition rules can also be included, which can be determined according to the actual business scenario, and this application does not impose any specific limitations.

[0210] For example, if a user inputs the data: "Please show me the sales and profit margin of the previous quarter", the intent is determined to be a query intent: "Query sales and profit margin". Based on the entity recognition model, the entities are determined to include: "last quarter", "profit margin" and "sales". By associating the query intent with the entities, it is determined that the indicators the user wants to query are "profit margin of the previous quarter" and "sales of the previous quarter", thus obtaining the indicators to be queried. The above example is for illustration only and is not specifically limited in this application.

[0211] It should be understood that the above-described method of obtaining the query indicator is one possible implementation, and other methods can also be used to obtain the query indicator, which this application does not limit.

[0212] S803: The data query system 200 searches for the query indicator in the graph model to determine whether the query logic has been obtained. If the query logic has been obtained, S804 and S807 are executed; otherwise, S805, S806, and S807 are executed.

[0213] As mentioned above, the graph model includes the mapping relationship between indicators and table data. If the graph model always includes the indicator to be queried, then the query logic of the indicator to be queried can be obtained according to the mapping relationship. The query logic includes the processing flow and the relevant table information of the physical tables and fields involved in the processing flow. Executing S804 based on the query logic can obtain the SQL statement corresponding to the input data.

[0214] As described above, the graph model includes a metadata layer and a semantic layer. The metadata layer includes a first mapping relationship between table data and metadata, while the semantic layer includes a second mapping relationship between metrics and metadata, and a third mapping relationship between metrics. If the queried metric is found in the graph model, multiple other metrics associated with the queried metric can be determined based on the third mapping relationship recorded in the graph model. The metadata associated with these other metrics can be determined based on the second mapping relationship recorded in the graph model. The table data associated with the metadata can be determined based on the first mapping relationship recorded in the graph model, thereby obtaining the processing flow of the queried metric and the physical table data involved in the processing flow, and thus obtaining the query logic. Of course, if the queried metric does not have a third mapping relationship with other metrics, the metadata associated with the queried metric can be determined based on the second mapping relationship recorded in the graph model, and then the table data associated with the metadata can be determined based on the first mapping relationship, thereby obtaining the processing flow and the physical table data involved in the processing flow. For details, please refer to the relevant descriptions in S310 and the embodiment in Figure 4, which will not be repeated here.

[0215] S804: The data query system 200 inputs the query logic into the translation model to obtain the SQL statement corresponding to the input data.

[0216] In practice, the translation model can create a semantic model based on the query flow and table information in the query logic, then integrate the table information into the semantic model to obtain an instance model, and then translate the corresponding SQL statement based on the instance model. For details of the translation model, please refer to the relevant descriptions in S350 and Figure 6, which will not be repeated here.

[0217] S805: The data query system 200 searches for the query indicator in the vector library and obtains prompt information for the query indicator.

[0218] Optionally, the prompt information includes the descriptive text or calculation formula of the indicator to be queried. Specifically, the vector library stores multiple vectors, each vector corresponding to a descriptive text or calculation formula of an indicator. By searching for the indicator to be queried in the vector library, the descriptive text or calculation formula corresponding to the indicator can be obtained, thus obtaining the prompt information. The description of the vector library can be found in S330, S340, and the relevant description in Figure 5, and will not be repeated here.

[0219] Optionally, the prompt information may also include relevant table information for the queried indicator. This relevant table information is obtained by retrieving the descriptive text or calculation formula from the graph model. The relevant table information includes information about some physical tables and fields involved in the reading process of the queried indicator. Specifically, after obtaining the descriptive text or calculation formula for the queried indicator from the vector library, sub-indicators can be extracted from the descriptive text or calculation rules. Then, the sub-indicators are retrieved in the graph model to obtain the metadata corresponding to the sub-indicators, as well as the table data corresponding to the metadata, thereby obtaining the relevant table information.

[0220] In practice, if the description text of the metric to be queried is a semantic explanation or a synonym explanation of the metric to be queried, and the sub-metric is a synonym of the metric to be queried, then the graph model includes the sub-metric. The query logic of the sub-metric can be obtained based on the graph model. Based on the query logic and the translation model, the SQL statement can be obtained.

[0221] Furthermore, if the description text of the metric to be queried is a semantic interpretation of the calculation logic of the metric to be queried, multiple sub-indicators can be obtained based on this calculation logic. If the graph model includes multiple sub-indicators, the query logic of multiple sub-indicators can be obtained based on the graph model. Then, based on the query logic of multiple sub-indicators and the calculation logic between multiple sub-indicators recorded in the description text, the query logic of the metric to be queried can be obtained. This query logic is input into the translation model to obtain the SQL statement.

[0222] Furthermore, if the graph model only includes some of the sub-indicators, the table data of these sub-indicators can be determined based on the graph model, and added as relevant table information to the prompt information. Then, the prompt information is input into the large language model to obtain the SQL statement.

[0223] Furthermore, if the graph model does not include the aforementioned sub-indicators, descriptive text or calculation formulas can be input as prompts into the large language model to obtain SQL statements.

[0224] It should be understood that the graph model records a large number of semantic metrics and semantic metadata, and records the mapping relationship between metrics and metadata, metadata and physical table data. The graph model is combined with the vector library to generate prompt information, which can help the large language model better understand the semantics of the input data and the data structure of the database, thereby generating more accurate SQL statements.

[0225] S806: The data query system 200 inputs the prompt information into the large language model and obtains the SQL statement corresponding to the input data.

[0226] In its implementation, the prompt information serves as a guide for the large language model, directing its output of SQL statements. During training, the large language model not only learns how to output SQL statements based on the prompt information but also learns the structural information of database 300, enabling it to output SQL statements usable in database 300. The relevant description of the large language model can be found in the description of S350, and this application does not impose specific limitations on it.

[0227] S807: Data query system 200 executes SQL statements in database 300 to obtain query results.

[0228] S808: The data query system 200 determines whether the intent includes an analysis intent. If it includes an analysis intent, executes S809 and S810; otherwise, executes S811. Specifically, the intent can be determined in step S802.

[0229] S809: The data query system 200 determines the analysis model based on the analysis intent, inputs the query results into the analysis model, and obtains the analysis results.

[0230] In its implementation, the data query system 200 can pre-train multiple analysis models. Different analysis models correspond to different analysis intentions. Each analysis model may include multiple processing steps and processing order, and each processing environment may include one or more processing steps. The data query system 200 can call the analysis models to process the query results and obtain the analysis results. The description of the analysis models can be found in the relevant descriptions in S360 and the embodiment in Figure 7, and will not be repeated here.

[0231] S810: The data query system 200 generates a response text based on the analysis results and sends the response text to the client 100.

[0232] Optionally, some predefined script templates can be used, each corresponding to a keyword. When a user sends input data, the input data can be matched with the keyword to determine the corresponding script template. Then, based on the analysis results, the script template is filled in to obtain the response text. The script template package can include fixed text and filler positions. The fixed text consists of words or sentences that will not change, while the filler positions need to be dynamically adjusted based on the analysis results. For example, if a user's question is, "What will the gross profit margin be next year?", and the query results show a predicted gross profit margin of A, the script template would be: "[Time]'s [Indicator] is [Analysis Result]". Here, "time" refers to next year, "indicator" refers to the gross profit margin, and "analysis result" refers to A. Combining this with the script template, the response text "Next year's gross profit margin is A" can be obtained. The above example is for illustration only and is not intended to be specific.

[0233] Optionally, a pre-trained natural language generation model, such as GPT or BERT, can be used to generate the response text. The input data and analysis results are input into the model to generate the response text. This application does not impose any specific limitations.

[0234] It should be understood that the above-described method for generating response text is for illustrative purposes only. This application may also use other methods to generate response text based on the analysis results, or to generate response text based on both the analysis results and the query results. This application does not impose any specific limitations.

[0235] S811: The data query system 200 generates a response text based on the query results and sends the response text to the client 100.

[0236] Similarly, when generating response text based on query results, the above-mentioned script template can be used to generate response text, or a natural language generation model can be used to generate response text, which will not be elaborated on here.

[0237] In the implementation shown in Figure 8, the data query system 200 includes a graph model and a vector library. The data query system 200 can execute S801 to S811 to obtain the response text corresponding to the input data.

[0238] In one possible implementation, the data query system 200 may only have a graph model, and the data query system 200 may execute S801~S804, S807~S811 to obtain the response text corresponding to the input data.

[0239] In another possible implementation, the data query system 200 may only have a vector library, and the data query system 200 may execute S801, S802, S805 to S811 to obtain the response text corresponding to the input data.

[0240] As can be seen from the foregoing, the data query system 200 provided in this application is implemented based on the AutoGen framework. This framework may include multiple agents, each of which is a customizable program or component that can communicate with each other and has specific functions. Therefore, agents can be flexibly allocated according to business needs to implement the above S801 to S811.

[0241] For example, if the graph model 201 and the vector library 202 are implemented by agent1, and agent1 is used to determine the query logic or prompt information of the queried indicator based on the input data, then agent1 can be used to execute S801-S803 and S805. If the generative model, namely the translation model and the large language model, is implemented by agent2, and agent2 is used to generate SQL statements and execute SQL statements to generate query results, specifically including generating SQL statements corresponding to the query logic based on the translation model and generating SQL statements corresponding to the prompt information based on the large language model, then agent2 can be used to execute S804, S806-S807.

[0242] For another example, if the analysis model is implemented by agent3, and agent3 is used to further analyze the query results based on the input data including the analysis intent, then agent3 can be used to execute S808 to S809. For yet another example, if the graph model 201 and the translation model are implemented by agent1, and the vector library 202 and the large language model are implemented by agent2—that is, agent1 is used to generate SQL based on the graph model 201, agent2 is used to generate SQL based on the vector library 202, and the analysis model is implemented by agent3 to generate the analysis results—in this case, agent1 can be used to execute S801 to S804 and S807, agent2 can be used to execute S805 to S807, and agent3 can be used to execute S808 to S809.

[0243] It should be understood that the examples above are for illustrative purposes. In actual implementation, the steps that the agent needs to execute can be flexibly set according to the actual application scenario. This application does not impose any specific limitations.

[0244] It should be understood that the above description, through steps S801 to S811, details the steps by which the data query system 200 obtains a response text based on a user-input query text. The beneficial effects of the data query method provided in this application will now be explained in conjunction with Figure 9. Figure 9 is an exemplary interface of a data query method provided in this application. This interface may include a question input area 910, a system response area 920, and a historical question display area 930.

[0245] The question input area 910 is used for users to send input data, and the query text is natural language text.

[0246] The system response area 920 is used to display the response text corresponding to the input data to the user.

[0247] The historical question display area 930 is used to display historical input data and historical response text to the user.

[0248] In the example shown in Figure 9, the user's first input is: "Please give me an analysis report for analysis indicator A." After receiving the above input data from the client 100, the data query system 200 executes S801-S802 to determine that the indicator to be queried is "analysis indicator A." Then, it executes S803, retrieving analysis indicator A from the graph model shown in Figure 4. Based on the third mapping relationship in the graph model, analysis indicator A needs to be determined according to the "Year-on-Year Net Sales Revenue" indicator and the "Target Threshold" indicator. The "Year-on-Year Net Sales Revenue" indicator needs to be determined according to the "Current Year Net Sales Revenue" indicator. The system uses the "net sales revenue last year" indicator to determine the mapping between the "target threshold" indicator and the metadata "target" based on the second mapping relationship. It also maps the "net sales revenue this year" indicator to the metadata "ydt" and the "time" indicator, and the "time" indicator to the metadata "time," and so on. This determines the query logic for indicator A, including the query process and the relevant table data. Then, step S804 is executed. Based on this query logic and the translation model, the SQL statement corresponding to the input data is obtained. Step S807 is then executed to obtain the query results for analyzing indicator A. Step S808 confirms that the input data has an analytical intent. Steps S808-S810 are then executed to obtain the analysis report for indicator A, generating a corresponding response text. The response text, "Okay, this is the analysis report for indicator A," is displayed in system response area 920, along with a download link for the report.

[0249] The second input data entered by the user is: "What was the gross profit margin of Company A last month?" After receiving the above input data sent by the client 100, the data query system 200 executes S801-S802 to determine that the query indicator is "gross profit margin", "last month", and "Company A". Then, it executes S803, and if it is determined that the gross profit margin does not exist in the graphical model shown in Figure 4, it executes S805 to search in the vector library shown in Figure 5 to obtain the descriptive text and calculation formula for "gross profit margin", and obtains a prompt message. Then, it executes S806 to input the prompt message into the large language model to obtain the corresponding SQL statement. Then, it executes S807 to obtain the query results. Then, it executes S808 to determine that the user's input data does not include the analysis intent, therefore, it executes S811 to generate a response text, which is displayed in the system response area 920 as: "Company A's gross profit margin last month was XXX. This is the gross profit margin report for last month," along with a download link for the report.

[0250] Understandably, this application enables data querying through the interface shown in Figure 9, allowing users to input natural language to obtain query and analysis results. Users do not need to learn about databases or the names of various tables, reducing the user's learning cost, improving query efficiency, and enhancing the user experience.

[0251] In summary, the data query method provided in this application, upon receiving natural language input data, first determines the indicator that the input data needs to retrieve. If the indicator exists in the graph model, the query logic corresponding to the input data is determined based on the mapping relationship between the indicator and table data in the graph model, and an SQL statement corresponding to the input data is generated based on the query logic. If the indicator does not exist in the graph model, the corresponding prompt information can be determined through a vector library, and the prompt information is input into the large language model to obtain the SQL statement. This ensures that even if the expression of the input data differs from the field expression in the database, or if the indicator requested by the input data does not exist in the database and needs to be obtained through a series of calculations using some fields in the database, the corresponding SQL statement for the input data can be obtained through the graph model or vector library. This allows users to flexibly and without restrictions input natural language text to complete queries, reducing the error rate of natural language queries and meeting users' query needs.

[0252] The data query method provided by this application has been described in detail above. The data query system provided by this application will be described below with reference to Figure 10. This data query system is the data query system 200 described in Figures 1 and 2.

[0253] Figure 10 is a schematic diagram of the structure of a data query system provided in this application. As shown in Figure 10, the data query system 200 includes an acquisition unit 1010, a graph model search unit 1020, a translation unit 1030, a vector library search unit 1040, a model reasoning unit 1050, a query unit 1060, an analysis unit 1070, and a response unit 1080. It should be understood that Figure 10 is an exemplary division method, and the data query system 200 can be divided into more or fewer unit modules, which is not specifically limited in this application.

[0254] The acquisition unit 1010, graph model search unit 1020, translation unit 1030, vector library search unit 1040, model inference unit 1050, query unit 1060, analysis unit 1070, and response unit 1080 can all be implemented in software or hardware. For example, the implementation of the graph model search unit 1020 will be described below. Similarly, the implementation of the acquisition unit 1010, translation unit 1030, vector library search unit 1040, model inference unit 1050, query unit 1060, analysis unit 1070, and response unit 1080 can refer to the implementation of the graph model search unit 1020.

[0255] The graph model search unit 1020, as an example of a software functional unit, may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the aforementioned computing instance may be one or more. For example, the graph model search unit 1020 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0256] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0257] The graph model search unit 1020, as an example of a hardware functional unit, may include at least one computing device, such as a server. Alternatively, the graph model search unit 1020 may be implemented using a central processing unit (CPU), an application-specific integrated circuit (ASIC), or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), a data processing unit (DPU), a neural network processing unit (NPU), a system-on-a-chip (SoC), an offload card, an accelerator card, or any combination thereof.

[0258] The multiple computing devices included in the graph model search unit 1020 can be distributed in the same region or in different regions. Similarly, the multiple computing devices included in the graph model search unit 1020 can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices included in the graph model search unit 1020 can be distributed in the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, GALs, DPUs, NPUs, SoCs, offloading cards, and accelerator cards.

[0259] It should be noted that, in other embodiments, the steps implemented by the acquisition unit 1010, graph model search unit 1020, translation unit 1030, vector library search unit 1040, model reasoning unit 1050, query unit 1060, analysis unit 1070, and response unit 1080 can be specified as needed. The acquisition unit 1010, graph model search unit 1020, translation unit 1030, vector library search unit 1040, model reasoning unit 1050, query unit 1060, analysis unit 1070, and response unit 1080 respectively implement different steps in the data query method to achieve all the functions of the data query system 200.

[0260] The functions of the acquisition unit 1010, graph model search unit 1020, translation unit 1030, vector library search unit 1040, model reasoning unit 1050, query unit 1060, analysis unit 1070, and response unit 1080 are explained below. Among them, the data query system 200 includes a vector library, which includes the descriptive text of the indicators and the calculation formula.

[0261] The acquisition unit 1010 is used to acquire input data, including the user's query data, and specifically implements S801 and its optional steps in the embodiment of Figure 8. The acquisition unit is used to obtain the query index requested by the user based on the input data, and specifically implements S802 and its optional steps in the embodiment of Figure 8. The search unit is used to confirm the data query result based on the query index using a multi-agent collaborative processing strategy. The multi-agent collaborative processing strategy indicates at least one method of data retrieval based on a graph model and a vector library, and specifically implements S803 and S805 in the embodiment of Figure 8. The response unit is used to present the data query result, and specifically implements S810 to S811 in the embodiment of Figure 8.

[0262] Furthermore, the search unit may include a graph model search unit 1020 and a vector library search unit 1040.

[0263] In one possible implementation, the graph model includes mapping relationships between multiple indicators and table data in the database. The graph model search unit 1020 is used to search for the indicator to be queried in the graph model. If the graph model includes the indicator to be queried, the query logic for the indicator to be queried is obtained based on the mapping relationships. Specifically, this is used to implement S803 and its optional steps in the embodiment of Figure 8. The translation unit 1030 is used to determine the structured query SQL statement for the input data based on the query logic. Specifically, this is used to implement S804 and its optional steps in the embodiment of Figure 8. The query unit is used to execute the SQL statement to obtain data query results. Specifically, this is used to implement S807 and its optional steps in the embodiment of Figure 8.

[0264] In one possible implementation, the vector library includes descriptive text and calculation formulas for multiple indicators. The vector library search unit 1040 is used to search for the query indicator in the vector library when the graph model does not include the query indicator, obtaining prompt information for the query indicator. The prompt information includes the descriptive text and calculation formula of the query indicator. Specifically, this is used to implement S805 and its optional steps in the embodiment of Figure 8. The model inference unit 1050 is used to input the prompt information into the large language model to obtain an SQL statement for the input data. Specifically, this is used to implement S806 and its optional steps in the embodiment of Figure 8. The query unit is used to execute the SQL statement to obtain data query results. Specifically, this is used to implement S807 and its optional steps in the embodiment of Figure 8.

[0265] In one possible implementation, the vector library search unit 1040 is used to obtain sub-indicators of the query indicator based on the descriptive text and calculation formula in the prompt information, wherein the sub-indicators are used to calculate the query indicator, or the sub-indicators are semantically similar to the query indicator. The graph model search unit 1020 is used to search for sub-indicators in the graph model. In the case that the graph model does not include sub-indicators, the graph model search unit 1020 is used to input the prompt information into the large language model to obtain a structured query SQL statement for the input data.

[0266] In one possible implementation, the vector library search unit 1040 is used to obtain the query logic of the sub-indicators based on the mapping relationship between the sub-indicators and table data when the graph model includes sub-indicators, and to determine the query logic of the indicator to be queried based on the query logic of the sub-indicators and the prompt information. The translation unit 1030 is used to determine the SQL statement based on the query logic of the indicator to be queried, and to execute the SQL statement to obtain the data query results.

[0267] In one possible implementation, the descriptive text in the vector library includes the semantic interpretation of the same indicator under different expressions, as well as the textual description of the computational logic under different expressions. The calculation formula in the vector library includes the calculation formula of the same indicator under different calculation methods.

[0268] In one possible implementation, the acquisition unit 1010 is used to determine the user's intent based on the input data, and the analysis unit 1070 is used to acquire the analysis model corresponding to the analysis intent when the intent includes the analysis intent, input the data query results into the analysis model, obtain the analysis results, and present the analysis results.

[0269] In one possible implementation, the large language model uses samples during training, including input data and corresponding labels. The input data includes input data samples and prompt information samples. The labels for the samples include the SQL statements corresponding to the input data samples. During training, the large language model injects database structure information into the model using a knowledge injection algorithm. This database structure information includes the physical mapping relationship between the semantics of table data and metadata. The specific training process of the large language model can be referred to as S350 and its optional steps in the embodiment shown in Figure 3.

[0270] It should be noted that the configuration process of the above graph model can refer to S310, S320 and their optional steps in the embodiment of Figure 3; the configuration process of the above vector library can refer to S330, S340 and their optional steps in the embodiment of Figure 3; the training process of the above translation model and large language model can refer to S350 and their optional steps in the embodiment of Figure 3; and the training process of the above analysis model can refer to S360 and their optional steps in the embodiment of Figure 3.

[0271] In summary, this application provides a data query system. Upon receiving natural language input data, the system first determines the indicator that needs to be retrieved. If the indicator exists in the graph model, the system determines the corresponding query logic based on the mapping relationship between the indicator and table data in the graph model, and generates the corresponding SQL statement based on the query logic. If the indicator does not exist in the graph model, the system can determine the corresponding prompt information through a vector library, and input the prompt information into the large language model to obtain the SQL statement. This ensures that even if the input data differs from the field representation in the database, or if the indicator requested by the input data does not exist in the database and requires calculations using some fields from the database, the corresponding SQL statement can be obtained through the graph model or vector library. This allows users to flexibly and without restrictions input natural language text to complete queries, reducing the error rate of natural language queries and meeting user query needs.

[0272] The data query method and data query system provided in this application have been described in detail above. The computing device provided in this application will be explained below with reference to Figures 11-13.

[0273] Figure 11 is a schematic diagram of a computing device provided in this application. As shown in Figure 11, the computing device 1100 includes: a bus 1102, a processor 1104, a memory 1106, and a communication interface 1108. The processor 1104, the memory 1106, and the communication interface 1108 communicate with each other via the bus 1102. The computing device 1100 can be a server. It should be understood that this application does not limit the number of processors, memories, and accelerator cards in the computing device 1100. The computing device 1100 can be used to deploy the data query system 200 in the embodiments of Figures 1-10 above. The memory 1106 is used to store instructions, and the processor 1104 is used to execute the instructions stored in the memory 1106. The memory 1106 stores program code, and the processor 1104 can call the program code stored in the memory 1106 to perform the following operations:

[0274] Obtain input data, which includes the user's query data;

[0275] Based on the input data, obtain the query metrics requested by the user;

[0276] The data query results are confirmed using a multi-agent collaborative processing strategy based on the query indicators. The aforementioned multi-agent collaborative processing strategy is used to indicate a way of data retrieval based on at least one of graph models and vector libraries.

[0277] The above data query results are presented.

[0278] It should be understood that the memory 1106 stores executable program code, and the processor 1104 executes the executable program code to implement the operation steps of the data query method described in each embodiment of Figures 3 to 10. The program code may include one or more software units, which are the acquisition unit, graph model search unit, query unit, vector library search unit, translation unit, response unit, analysis unit, and model reasoning unit in the embodiment of FIG10. The acquisition unit is used to implement S801, S802 and their optional steps in the embodiment of FIG8. The graph model search unit is used to implement S803 and its optional steps in the embodiment of FIG8. The vector library search unit is used to implement S805 and its optional steps in the embodiment of FIG8. The translation unit is used to implement S804 and its optional steps in the embodiment of FIG8. The model reasoning unit is used to implement S806 and its optional steps in the embodiment of FIG8. The query unit is used to implement S807 and its optional steps in the embodiment of FIG8. The analysis unit is used to implement S808, S809 and their optional steps in the embodiment of FIG8. The response unit is used to implement S810, S811 and its optional steps in the embodiment of FIG8. The details of each unit will not be elaborated here.

[0279] Bus 1102 can be a Peripheral Component Interconnect Express (PCIe) bus, an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (Ubus or UB), a Compute Express Link (CXL), a Cache Coherent Interconnect for Accelerators (CCIX), etc. The Unified Bus is also known as the Lingqu Bus. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, only one line is used in Figure 11, but this does not imply that there is only one bus or one type of bus. Bus 1102 can include pathways for transmitting information between various components of computing device 1100 (e.g., memory 1106, processor 1104, communication interface 1108). The Unified Bus can also be referred to as the Lingqu Bus.

[0280] The processor 1104 may include any one or more of the following computing devices: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP) or digital signal processor (DSP), ASIC, FPGA, CPLD, NPU, SoC, offload card, accelerator card, etc.

[0281] Memory 1106 may include volatile memory, such as random access memory (RAM). Memory 1106 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD). Furthermore, memory 1106 may also be implemented using storage class memory (SCM), phase change memory (PCM), or other types of storage media.

[0282] It is worth noting that the same type of storage medium can be configured in the same computing device to realize the function of memory 1106, or two or more types of storage media can be configured to realize the function of memory 1106. This application does not limit this.

[0283] The communication interface 1108 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 1100 and other devices or communication networks.

[0284] It should be understood that the computing device 1100 described above in this application may correspond to the analysis model or data query system 200 described in FIG7 or FIG10 of this application, and may correspond to the corresponding subject executing the method described in FIG3 to FIG6, FIG8 or FIG9 of this application. The above and other operations and / or functions of each module in the computing device 1100 are respectively for implementing the corresponding processes of each method in FIG3 to FIG10. For the sake of brevity, they will not be described in detail here.

[0285] As one possible implementation, the methods described in Figures 3 to 10 can be implemented either by the processor in the computing device 1100 executing the program code in the memory, or by the accelerator card 1107 in the computing device 1100. The accelerator card 1107 can be implemented by computing devices such as DPU, NPU, GPU, XPU, SoC, or AI chips; this application does not specifically limit its implementation. The accelerator card 1107 includes a processing unit and a power supply circuit. The power supply circuit supplies power to the processing unit, enabling the processing unit to execute the operation steps of the data query method described in each embodiment of Figures 3 to 10. For example, the processing unit can implement the functions of the acquisition unit, graph model search unit, query unit, vector library search unit, translation unit, response unit, analysis unit, and model inference unit. The functional descriptions of these multiple units can be found in the relevant content above, and will not be repeated here.

[0286] As one possible implementation, the methods described in Figures 3 to 10, besides being executed by the processor in computing device 1100 executing the program code in memory, or implemented by accelerator card 1107, can also be implemented by a combination of processor 1104 in computing device 1100 and accelerator card 1107, which together implement the operation steps performed by the corresponding entities in the data query methods described in Figures 3 to 10. Specifically, the program code stored in memory 1106 includes some unit modules shown in Figure 10, causing processor 1104 to execute the program code to implement some operation steps of the data query method. The power supply circuit in accelerator card 1107 supplies power to the processing unit, causing the processing unit to execute another part of the operation. For example, memory 1106 stores program code for an acquisition unit, a query unit, a translation unit, a response unit, an analysis unit, a vector library search unit, and a graph model search unit. The processing unit of accelerator card 1107 is used to implement the function of the model inference unit. The above examples are for illustration only and are not specifically limited in this application. Furthermore, the functional descriptions of the above multiple units can be found in the relevant content above, and will not be repeated here.

[0287] This application also provides a computing device cluster. As shown in Figure 12, which is an example diagram of a computing device cluster provided in this application, the computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0288] As one possible implementation, the memory 1106 of one or more computing devices 1100 in a computing device cluster may store the same instructions for implementing the operation steps of the data query method described in Figures 3 to 10. Alternatively, the memory 1106 of one or more computing devices 1100 may store different instructions for implementing the operation steps of the data query method described in Figures 3 to 10. In other words, a combination of one or more computing devices 1100 can jointly execute the instructions for implementing the operation steps required by the data query method.

[0289] As one possible implementation, the accelerator cards 1107 in one or more computing devices 1100 in a computing device cluster may store the same instructions for implementing the operation steps of the data query method described in Figures 3 to 10. Alternatively, the accelerator cards 1107 of one or more computing devices 1100 may each store different instructions for implementing the operation steps of the data query method described in Figures 3 to 10. In other words, a combination of one or more computing devices 1100 can jointly execute the instructions for implementing the operation steps required by the data query method.

[0290] As one possible implementation, the memory 1106 of one or more computing devices 1100 in the computing device cluster stores the same instructions for implementing a portion of the operation steps of the data query method described in Figures 3 to 10, and the accelerator card 1107 stores the same instructions for implementing another portion of the operation steps. Alternatively, the memory 1106 of one or more computing devices 1100 may also store different instructions for implementing a portion of the operation steps of the data method described in Figures 3 to 10, and the accelerator card 1107 may store different instructions for implementing another portion of the operation steps. In other words, a combination of one or more computing devices 1100 can jointly execute the instructions for implementing the operation steps required by the data query method.

[0291] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 13 illustrates one possible implementation. As shown in Figure 13, Figure 13 is a schematic diagram of another computing device cluster structure provided in this application. Two computing devices, 1100A and 1100B, are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this type of possible implementation, the memory 1106 in computing device 1100B stores instructions for the functions of an acquisition unit, a response unit, a translation unit, an analysis unit, and a graph model search unit. Meanwhile, the accelerator card 1107 in computing device 1100A stores instructions for executing the model inference unit, and the memory 1106 stores instructions for executing the vector library search unit.

[0292] The connection method between the computing device clusters shown in Figure 13 can be based on the fact that data query systems are usually distributed systems. In order to reduce the processing pressure of each device, the unit modules are distributed on different computing devices.

[0293] It should be understood that the functions of computing device 1100A shown in Figure 13 can also be performed by multiple computing devices 1100. Similarly, the functions of computing device 1100B can also be performed by multiple computing devices 1100.

[0294] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute a reasoning method based on a large language model.

[0295] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute a reasoning method based on a large language model, or instruct the computing device to execute a reasoning method.

[0296] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

Claims

1. A data query method, characterized by, The method is executed by a data query system, comprising: obtaining input data, the input data comprising data to be queried by a user; obtaining an index to be queried requested by the user based on the input data; confirming a data query result according to the index to be queried by using a multi-agent collaborative processing strategy, the multi-agent collaborative processing strategy being used to indicate a manner of data retrieval based on at least one of a graph model and a vector library; presenting the data query result.

2. The method of claim 1, wherein, The graph model comprises a mapping relationship between a plurality of indexes and table data in a database; The confirming of the data query result according to the index to be queried by using the multi-agent collaborative processing strategy comprises: searching the index to be queried in the graph model; in a case where the graph model comprises the index to be queried, obtaining query logic of the index to be queried according to the mapping relationship; determining a structured query language (SQL) statement of the input data based on the query logic, executing the SQL statement to obtain the data query result.

3. The method according to claim 1 or 2, characterized in that, The vector library comprises description texts and calculation formulas of a plurality of indexes; The confirming of the data query result according to the index to be queried by using the multi-agent collaborative processing strategy comprises: in a case where the graph model does not comprise the index to be queried, searching the index to be queried in the vector library to obtain prompt information of the index to be queried, the prompt information comprising description texts and calculation formulas of the index to be queried; inputting the prompt information into a large language model to obtain an SQL statement of the input data, executing the SQL statement to obtain the data query result.

4. The method of claim 3, wherein, The inputting of the prompt information into the large language model to obtain the structured query language (SQL) statement of the input data comprises: obtaining sub-indexes of the index to be queried according to the description texts and the calculation formulas in the prompt information, wherein the sub-indexes are used to calculate the index to be queried, or the sub-indexes are semantically similar to the index to be queried; searching the sub-indexes in the graph model; in a case where the graph model does not comprise the sub-indexes, inputting the prompt information into the large language model to obtain the structured query language (SQL) statement of the input data.

5. The method of claim 4, wherein, The method further comprises: in a case where the graph model comprises the sub-indexes, obtaining query logic of the sub-indexes according to a mapping relationship between the sub-indexes and table data, and determining query logic of the index to be queried based on the query logic of the sub-indexes and the prompt information; determining the SQL statement based on the query logic of the index to be queried, and executing the SQL statement to obtain the data query result.

6. The method according to any one of claims 1 to 5, characterized in that, The description texts in the vector library comprise semantic interpretations of the same index in different expression manners, and textual descriptions of calculation logic in different expression manners, and the calculation formulas in the vector library comprise calculation formulas of the same index in different calculation manners.

7. The method according to any one of claims 1 to 5, characterized in that, The method further comprises: determining an intention of the user based on the input data; In a case where the intent includes an analysis intent, an analysis model corresponding to the analysis intent is acquired, the data query result is input into the analysis model, an analysis result is obtained, and the analysis result is presented.

8. A data query system, characterized by, The system comprises: An acquisition unit is configured to acquire input data, the input data comprising to-be-queried data of a user; The acquisition unit is configured to obtain a to-be-queried index requested by the user based on the input data; A searching unit is configured to confirm a data query result by using a multi-agent collaborative processing strategy according to the to-be-queried index, the multi-agent collaborative processing strategy being used to indicate a manner of implementing data retrieval based on at least one of a graph model and a vector library; A reply unit is configured to present the data query result.

9. The system of claim 8, wherein, The graph model comprises a mapping relationship between a plurality of indexes and table data in a database, and the system comprises a translation unit and a query unit; The searching unit is configured to search for the to-be-queried index in the graph model; In a case where the graph model comprises the to-be-queried index, the searching unit is configured to obtain query logic of the to-be-queried index according to the mapping relationship; The translation unit is configured to determine a structured query SQL statement of the input data based on the query logic; The query unit is configured to execute the SQL statement to obtain the data query result.

10. The system of claim 8 or 9, characterized in that, The vector library comprises description texts and calculation formulas of a plurality of indexes, and the system comprises a model reasoning unit; In a case where the graph model does not comprise the to-be-queried index, the searching unit is configured to search for the to-be-queried index in the vector library to obtain prompt information of the to-be-queried index, the prompt information comprising description texts and calculation formulas of the to-be-queried index; The model reasoning unit is configured to input the prompt information into a large language model to obtain a SQL statement of the input data; The query unit is configured to execute the SQL statement to obtain the data query result.

11. The system of claim 10, wherein The searching unit is configured to obtain a sub-index of the to-be-queried index according to the description texts and the calculation formulas in the prompt information, wherein the sub-index is used to calculate the to-be-queried index, or the sub-index is semantically similar to the to-be-queried index; The searching unit is configured to search for the sub-index in the graph model; In a case where the graph model does not comprise the sub-index, the model reasoning unit is configured to input the prompt information into the large language model to obtain a structured query SQL statement of the input data.

12. The system of claim 11, wherein In a case where the graph model comprises the sub-index, the searching unit is configured to obtain query logic of the sub-index according to a mapping relationship between the sub-index and table data, and determine query logic of the to-be-queried index based on the query logic of the sub-index and the prompt information; The translation unit is configured to determine the SQL statement based on the query logic of the to-be-queried index, and execute the SQL statement to obtain the data query result.

13. The system of any of claims 8 to 12, wherein, The description text in the vector library includes semantic explanations of the same index in different expression manners, and the calculation formula in the vector library includes calculation formulas of the same index in different calculation manners.

14. The system of any of claims 8 to 13, wherein, The system comprises an analysis unit, The acquisition unit is configured to determine the intention of the user based on the input data. The analysis unit is configured to, when the intention comprises an analysis intention, acquire an analysis model corresponding to the analysis intention, input the data query result into the analysis model, obtain an analysis result, and present the analysis result.

15. A computing device, comprising: The computing device comprises a processor and a memory; The processor is configured to execute instructions stored in the memory, so that the computing device performs the operation steps of the method according to any one of claims 1 to 7.

16. A computer readable storage medium, characterized in that, Computer program instructions are included, when the computer program instructions are executed by a computing device cluster, the computing device cluster performs the operation steps of the method according to any one of claims 1 to 7.

17. A computer program product comprising instructions, characterized in that, When the instructions are run by a computing device or a computing device cluster, the computing device or the computing device cluster performs the operation steps of the method according to any one of claims 1 to 7.

Images