Methods, systems, and computer programs (dynamic graph scaling search for generating complex structured query languages ​​based on graph databases and large-scale language models)

Abstract

This invention provides methods, systems, and computer program products for dynamic graph scaling exploration for generating complex structured query languages ​​based on graph databases and large-scale language models. [Solution] The method includes generating data for constructing a structured query language (SQL) based on semantic information, defining and extracting entities from a database via a large-scale language model (LLM), and incorporating this data into a multi-layer semantic routable graph; and determining nodes related to user queries based on the multi-layer semantic routable graph.

Description

Technical Field

[0001] Embodiments relate to a method, system, and computer program product for dynamic graph scaling search for the generation of complex structured query languages based on graph databases and large language models.

Background Art

[0002] Structured Query Language (SQL) is a language used to manage data and is generally used in relational database management systems (RDBMS). SQL can be useful for handling structured data, which incorporates relationships between entities and variables. A simple SQL query is usually a command that performs a simple data retrieval from only one table at a time, while a complex SQL query goes beyond the realm of standard commands by retrieving data from multiple tables and limiting the result set using multiple conditions.

[0003] A large language model (LLM) is a type of computational model for natural language processing (NLP) tasks such as language generation. An LLM can perform NLP tasks by learning statistical relationships from a large amount of text during the training process. A particular LLM is an artificial neural network built with a decoder-only transformer-based architecture. An LLM can be fine-tuned for a specific task or guided by prompt engineering.

[0004] A graph database is a type of database that uses a graph model to store and represent data, and can be optimized for connected data. Unlike relational databases, which store data in tables, graph databases store data using a network of entities and relationships. Graph databases represent and store data using a graph structure with nodes, edges, and properties. The graph associates data items in the database with a set of nodes and edges, where the edges represent the relationships between nodes. [Overview of the Initiative] [Problems that the invention aims to solve]

[0005] To generate accurate SQL statements based on existing data, the process may need to provide the LLM with table schemas, table descriptions, and relationships between tables. However, this mechanism has many limitations when dealing with large databases. [Means for solving the problem]

[0006] Methods, systems, and computer program products are provided in which entities are defined and extracted from a database based on semantic information via a Large-Scale Language Model (LLM). Data for Structured Query Language (SQL) generation is generated to be incorporated into a multi-layer semantic routable graph. Nodes relevant to user queries are determined based on the multi-layer semantic routable graph.

[0007] In an additional embodiment, the LLM is used to construct the multi-layer semantic routable graph based on table schemas, table and column descriptions, and SQL syntax operation commands.

[0008] In an additional embodiment, the multilayer semantic routable graph stores the schemas of tables and the relationships between different tables.

[0009] In a further embodiment, the LLM is used to extend, refine, and decompose user query tasks.

[0010] In a particular embodiment, the multilayer semantic routable graph is used to filter nodes that are strongly related to each query subtask.

[0011] In a further embodiment, a ternary graph is defined to represent the relationships between tables and SQL keywords in order to generate complex SQL.

[0012] In further embodiments, the process generates SQL based on the computed subgraphs and performs operations for dynamic graph scaling on the graph search to determine the final SQL statement. [Brief explanation of the drawing]

[0013] Next, refer to the following drawings, where the same reference numerals throughout represent the corresponding parts. [Figure 1] This describes a computing environment according to a specific embodiment. [Figure 2] A block diagram is shown illustrating the construction of a hierarchical graph based on database structure information according to a specific embodiment. [Figure 3] A block diagram showing SQL syntax keyword nodes according to a specific embodiment is shown. [Figure 4] A block diagram showing the ternary relationship between three types of nodes according to a specific embodiment is shown. [Figure 5] A block diagram illustrating semantic relationships in a specific embodiment is shown. [Figure 6] A block diagram showing the correspondence based on query history according to a specific embodiment is provided. [Figure 7] A block diagram illustrating the construction of a basic node graph according to a specific embodiment is shown. [Figure 8]A block diagram showing a dynamic graph scaling search operation according to a specific embodiment is shown. [Figure 9] A flowchart showing exemplary operations according to a specific embodiment is shown. [Figure 10] A computing environment in which a specific component can be implemented according to a specific embodiment is shown. **DETAILED DESCRIPTION OF THE INVENTION**

[0014] In the following description, reference is made to the accompanying drawings which form a part hereof and which illustrate several embodiments. It is understood that other embodiments may be utilized and that structural and operational changes may be made.

[0015] To further clarify various aspects of the present invention, several examples are provided here.

[0016] Example 1: A method for defining and extracting entities from a database based on semantic information via a large language model (LLM). Data for structured query language (SQL) generation is generated for incorporation into a multi-layer semantic routing-capable graph. Nodes related to a user query are determined based on the multi-layer semantic routing-capable graph. As a result, the user query can be understood and analyzed.

[0017] Example 2: The limitation of Example 1 where the LLM is used to construct the multi-layer semantic routing-capable graph based on table schemas, descriptions of tables and columns, and SQL syntax manipulation commands. As a result, the LLM enlarges tables and table schemas to analyze user queries.

[0018] Example 3: The limitation of either Example 1 or Example 2 where the multi-layer semantic routing-capable graph stores table schemas and relationships between different tables. As a result, a better understanding of user queries is achieved.

[0019] Example 4: The LLM is limited by any of Examples 1 to 3 and is used to expand, refine, and decompose user query tasks. As a result, the LLM is applied to refine user query tasks.

[0020] Example 5: The multi-layer semantic routing-capable graph is limited by any of Examples 1 to 4 and is used to filter nodes strongly related to each query subtask. As a result, the nodes related to the query subtasks are determined.

[0021] Example 6: To generate complex SQL, a ternary graph representing the relationship between tables and SQL keywords is defined, limited by any of Examples 1 to 5. As a result, complex SQL statements are generated.

[0022] Example 7: The process performs an operation of dynamic graph scaling for graph exploration to generate SQL generation based on the calculated subgraph and determines the final SQL statement, limited by any of Examples 1 to 6. As a result, dynamic graph scaling for graph exploration is performed.

[0023] Example 8: A system comprising a memory and a processor coupled to the memory, where the processor implements the method described in any of Examples 1 to 7.

[0024] Example 9: A computer program product comprising a computer-readable storage medium having computer-readable program code embodied therein, where the computer-readable program code is configured to implement the method described in any of Examples 1 to 7 when executed by a processor.

[0025] Generating SQL with the help of an LLM and using the generated SQL to query data from a database may be adopted for certain purposes. To generate accurate SQL statements based on existing data, the process may need to provide the LLM with table schemas, table descriptions, and relationships between tables. However, this mechanism has many limitations when dealing with large databases. For example, due to limitations on the length of input tokens, it may be impossible for the process to provide complete information about the database in the model prompts. It is difficult to accurately find the tables and columns relevant to user queries from large databases and to streamline the input tokens for generating accurate SQL statements. When using an LLM to generate executable SQL based on retrieved target tables and columns, several limitations still exist, such as multi-table joins, dimension aggregation, and complex key performance indicator (KPI) calculations.

[0026] When dealing with large-scale database scenarios, it is not practical to provide all information about tables in the prompt. Instead, the process may need to find a way to dynamically insert the most relevant information into the final prompt. Certain embodiments apply LLM to construct a graph structure based on table schemas, table / column descriptions, and common SQL syntax manipulation commands. The constructed graph stores the schemas of tables and the relationships between different tables. To resolve tokenization limitations and ensure the accuracy of complex SQL generation, the process may expand and decompose the user's original query using a large-scale model, and may also use semantic information and the graph to filter nodes that are strongly relevant to each query subtask. Certain embodiments also provide a dynamic graph scaling search algorithm to simulate SQL generation based on the computed subgraph and obtain the final SQL statement.

[0027] Certain embodiments address at least the following problems when generating complex SQL in large databases: (1) How to find the most relevant data tables and data columns in a large database from a user query and reduce the length of the input data in order to avoid the context input length limitation in LLM; and (2) How to get the model to accurately generate complex query statements that match user requirements, and how to solve tasks such as joining multiple tables, statistical methods, and complex keyword calculations during the SQL generation process.

[0028] A specific embodiment addresses the two problems described above by combining a graph database with a large-scale language model and a dynamic graph scaling application.

[0029] In certain embodiments, an offline hierarchical graph construction process is employed. In the hierarchical graph construction process, graph nodes are related to tables using at least primary and foreign keys to establish relationships between different table nodes. Sample data and semantic information of columns are used to establish relationships between column nodes.

[0030] The hierarchical graph construction process also generates an SQL syntax graph by using LLM to extract common SQL operation commands from database documents, such as SQL keywords and statistical commands. Relationships are the dependencies and application rules between different operation commands.

[0031] The hierarchical graph construction process also generates an augmented graph by mining potential business relationships between data tables based on query history and table semantic information.

[0032] The hierarchical graph construction process also generates a rich graph structure by determining potential relationships between tables. This may be done by constructing unowned foreign key relationships based on query history and semantic information between tables.

[0033] Online inference is performed by searching and generating subgraphs from a constructed graph based on user queries, generating SQL, and then performing simulations, evaluations, and rankings.

[0034] A particular embodiment decomposes user queries based on LLM and then uses a multi-level hierarchical mechanism to explore strongly related table nodes from a higher-dimensional data level.

[0035] Based on the target table and column nodes, a particular embodiment selects the following SQL operations to be executed in conjunction with the query history: (1) stepwise queries; (2) join queries; and (3) statistical query commands.

[0036] In certain embodiments, a subgraph is generated based on matched nodes. SQL generation and simulation are performed. In certain embodiments, the simulation results are also evaluated based on the following metrics: (1) SQL syntax correctness; (2) query performance; and (3) correlation (based on LLM) between query data and user queries. In certain embodiments, the results are sorted based on the evaluation score. As a result, improvements are made to the computing device that performs the database operations.

[0037] Figure 1 shows a computing environment 100 according to a specific embodiment. At least one computing device 102 is connected to a network 104 in the computing environment 100.

[0038] The computing device 102 runs a dynamic graph scaling application 106 that uses the LLM 108 to generate a graph database 110. In certain embodiments, the dynamic graph scaling application 106 and the LLM 108 may be implemented in hardware, firmware, software, or any combination thereof.

[0039] In certain embodiments, the computing device 102 may include any suitable computing device known in the art, such as a server, personal computer, laptop, or mainframe. The network 104 may include any suitable network known in the art, such as the Internet, local area network, or wide area network. Adapters, routers, switches, etc., may connect the computing device 102 to the network 104.

[0040] Figure 2 shows a block diagram 200 illustrating the construction of a hierarchical graph based on database structure information according to a specific embodiment.

[0041] Database 202 is shown, containing the first table 204 and data fields referred to as Field 1 206, Field 2 208, and Field 3 210. The second table 212 and its data fields 214, 216, and 218 are also shown. Exemplary relationships R1 224, R2 226, R3 228, and R4 230 are shown.

[0042] A graph data structure is a data structure that shows the relationships between nodes. In a large number of data tables, complex correspondences exist between different data tables and data fields, which can make traditional querying methods very cumbersome and inefficient. To solve this problem, the embodiment provides a hierarchical graph based on data tables and a database syntax graph.

[0043] A hierarchical graph is constructed based on information related to the structure of database 202 (as shown via reference numeral 222). The hierarchical graph consists of three layers, referred to as layer 1, which contains the sparse layer 232; layer 2, which contains the intermediate layer 234; and layer 3, which contains the densest layer 236.

[0044] The sparse layer 232 contains the core nodes of the table and relationships based on semantic information. The intermediate layer 234 contains table nodes and exemplary relationships. The densest layer 236 contains field nodes and relationships including the same table relationships and primary key / foreign key relationships.

[0045] The node types of the hierarchical graph may include table nodes and field nodes, and if there are too many schemas, the embodiment may add schema nodes and add layers to which the schemas belong.

[0046] In a particular embodiment, exemplary relationships include: (1) relationships with schema tables; (2) strong primary foreign key correspondences between tables; (3) latent table relationships based on LLM exploration (using LLM to discover latent relationships between tables with table descriptions and field information as input); and (4) relationships with table fields.

[0047] In a particular embodiment, a query history record 238 is used to establish a query relationship, with the query keyword being used as an intermediate node.

[0048] Figure 3 shows a block diagram 300 illustrating SQL syntax keyword nodes according to a specific embodiment.

[0049] Because the SQL syntax document 302 is rich in content, certain embodiments may extract keywords from the official SQL syntax document, development documentation, and LLM-based best practices, and associate the content of these relevant documents with keyword nodes in mount 304. When SQL is generated, the semantic information of the SQL is used to find the keyword nodes. The embodiment may then decide whether to use the keyword and identify any subsequent operations required to use the keyword, depending on the document corresponding to the keyword.

[0050] Figure 4 shows a block diagram 400 illustrating a ternary relationship between three types of nodes 402, 404, and 406 according to a specific embodiment.

[0051] In certain embodiments, node relationships based on query history are constructed in a ternary subgraph, allowing direct navigation of higher-level semantic relationships to specific syntactic nodes, and then rapid extraction of other related nodes.

[0052] Figure 5 shows a block diagram 500 illustrating semantic relationships according to a specific embodiment.

[0053] In addition to strong correspondences (rigid correspondences) with primary foreign keys and schemas, semantic and similarity / proximity relationships (flexible correspondences) exist between tables. Figure 5 shows semantic-based correspondences for expanding the edges between nodes.

[0054] In a particular embodiment, the embedding 502 is generated from the table name, table description, field name, and field type (indicated by reference numeral 504). From the embedding 502, a semantic vector 505 and a relation 506 are generated, and a graph 508 is constructed.

[0055] Figure 6 shows a block diagram 600 illustrating a correspondence based on query history according to a specific embodiment. The query history 602 is used on LLM 604, and the correspondence is generated based on table 606 and keyword 608, which is shown in graph 610.

[0056] Figure 7 shows a block diagram 700 illustrating the construction of a basic node graph 702 according to a specific embodiment.

[0057] In actual query tasks, due to the complexity of business rules, the LLM may not understand user 706's query 704. Therefore, to enable the LLM to better understand query tasks, operations performed in certain embodiments are based on the LLM in combination with an existing table schema, and such embodiments use semantic information to decompose user queries and achieve the objective of extending or refining user query tasks in order to help the LLM better understand all user query tasks.

[0058] During the expansion and refinement of a query task, certain embodiments use the semantic information of the user's original query as a baseline to calculate the semantic similarity between the expanded and refined tasks and the original task, thereby aligning the intent accordingly. This controls the boundaries and scope of the LLM expansion. Task refinement stops when a specified number of iterations are reached.

[0059] When a task is received, a hierarchical search is performed in the graph based on the task's semantic information to find the relevant table and field nodes. Simultaneously, SQL keyword nodes are extracted based on node relationships, resulting in the basic node subgraph 702 shown in Figure 7.

[0060] Figure 8 shows a block diagram 800 illustrating a dynamic graph scaling search operation according to a specific embodiment.

[0061] Complex user queries involve underlying tasks that need to be placed in a specific logical order to complete data queries and integrations through correct logical relationships. A particular embodiment uses an existing task list and employs a large-scale predictive model to arrange the tasks and obtain the task sequence.

[0062] For each query task, a particular embodiment explores the nodes relevant to the current task by starting at the node most semantically closest to the query task and performing a random walk 802 along the edges between graph nodes. After reaching a new node, the particular embodiment first uses LLM to determine whether the currently visited nodes are sufficient to generate the SQL required for the query task. The particular embodiment continues the random walk until all nodes required for the current query task have been visited, then generates SQL 804, and then verifies its accuracy. Based on the verification results, the particular embodiment decides whether to backtrack to optimize the generated SQL.

[0063] As SQL is generated for the query tasks in this iteration, a particular embodiment updates the current graph based on the LLM, removing data table nodes that are no longer needed and inserting new data table nodes into the graph based on the completed query tasks to represent the results of the subordinate query tasks. The above process is repeated in a cycle until all query tasks are completed.

[0064] During each random walk for node questing, the system maintains multiple results corresponding to various SQL formulations. The goal of this approach is to quickly identify nodes available for verification during SQL optimization backtracking and to ensure the accuracy of SQL generation.

[0065] These multiple results are ranked based on the following complex key performance metrics: (1) syntax correctness (successful execution in the database); (2) query response speed; (3) relevance of query results to the query task; (4) relevance of query results to the initial user query (task deviation and task consistency); and (5) path length of involved nodes in the graph (to ensure the most concise SQL is generated).

[0066] Figure 9 shows a flowchart 900 illustrating exemplary operations according to a particular embodiment. In a particular embodiment, the operations shown in Figure 9 may be performed by a dynamic graph scaling application 106 executed on a computing device 102.

[0067] Control begins in block 902, where entities are defined and extracted from the database via a Large-Scale Language Model (LLM) based on semantic information. Data for Structured Query Language (SQL) generation is generated for incorporation into a multi-layer semantic routable graph (in block 904). Nodes relevant to user queries are determined based on the multi-layer semantic routable graph (in block 906).

[0068] Therefore, Figures 1 to 9 illustrate a specific embodiment in which LLM is used to define and extract entities based on semantic information and to provide a mechanism for constructing data related to SQL generation into a multi-layer semantic routable graph. The ternary graph is defined to represent the relationships between tables and SQL keywords, assisting in the high-precision generation of complex SQL. LLM is used to extend, refine, and decompose user query tasks. Based on the multi-layer semantic routable graph structure, nodes related to user queries are determined. A dynamic graph scaling algorithm for graph exploration is proposed.

[0069] Based on a graph database that stores large amounts of table data, it is possible to effectively maintain complex relationships between tables, fields, and SQL keywords. By extending and decomposing original user queries with a large-scale language model, a more rigorous understanding of user query tasks is achieved, revealing potential nested subqueries. The hierarchical routable graph search algorithm utilizes semantic information and relationships between nodes to implement graph-level "skip-list queries," enabling rapid nearest neighbor node search that can complete in milliseconds, even for searches involving millions of nodes.

[0070] In certain embodiments, dynamic graph scaling applications employ a random walk mechanism to ensure traceability of node visits and provide safeguards for accurate SQL generation. By pre-filtering relevant data, token usage is reduced, thereby better fitting token limitations to large language models. Fewer tokens also reduce the operational cost of large language models and improve the accuracy of task understanding.

[0071] Various aspects of this disclosure are described by explanatory text, flowcharts, block diagrams of computer systems and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flowchart, depending on the technology involved, operations may be performed in a different order than those shown in a given flowchart. For example, again, depending on the technology involved, two operations shown in consecutive blocks of a flowchart may be performed in reverse order, as a single integrated stage, simultaneously, or with at least partial time overlap.

[0072] Computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also called "mediums") that collectively comprise a set of one or more storage devices that collectively comprise machine-readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP claim. A "storage device" is any tangible device capable of holding and storing instructions for use by a computer processor. Computer-readable storage media may be, but are not limited to, electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, mechanical storage media, or any preferred combination thereof. Some known types of storage devices, including these media, include: diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices (such as pits / lands formed on the main surface of a punch card or disk), or any suitable combination of the foregoing. When the term "computer-readable storage medium" is used in this disclosure, it shall not be construed as storage in the form of transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses passing through optical fiber cables, electrical signals communicated through wires, and / or other transmitting media.As will be understood by those skilled in the art, data is typically moved at several incidental points during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device transient, because data is not transient while it is stored.

[0073] In Figure 10, the computing environment 1200 includes an example of an execution environment for at least some computer code (block 1250) involved in performing the operations for the dynamic graph scaling application 1260 that performs the operations shown in Figures 1 to 9.

[0074] In addition to block 1250, the computing environment 1200 includes, for example, a computer 1201, a wide area network (WAN) 1202, an end user device (EUD) 1203, a remote server 1204, a public cloud 1205, and a private cloud 1206. In this embodiment, computer 1201 includes a processor set 1210 (including processing circuits 1220 and a cache 1221), a communication fabric 1211, volatile memory 1212, persistent storage 1213 (including an operating system 1222 and block 1250 as identified above), a peripheral device set 1214 (including a user interface (UI) device set 1223, storage 1224, and an Internet of Things (IoT) sensor set 1225), and a network module 1215. The remote server 1204 includes a remote database 1230. Public cloud 1205 includes gateway 1240, cloud orchestration module 1241, host physical machine set 1242, virtual machine set 1243, and container set 1244.

[0075] Computer 1201 may take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device currently known or to be developed in the future that is capable of running programs, accessing networks, or querying databases such as remote database 1230. As is well understood in the field of computer technology, and depending on the technology, the execution of the computer implementation method may be distributed among multiple computers and / or across multiple locations. On the other hand, in this proposal of computing environment 1200, detailed considerations are focused on a single computer, specifically computer 1201, in order to keep this proposal as simple as possible, although computer 1201 may be located in the cloud, even if not shown in the cloud in Figure 6. On the other hand, computer 1201 is not required to be located in the cloud, except to any extent that can be definitively shown.

[0076] The processor set 1210 includes one or more computer processors of any type currently known or to be developed in the future. The processing circuitry 1220 may be distributed across multiple packages, e.g., multiple coordinated integrated circuit chips. The processing circuitry 1220 may implement multiple processor threads and / or multiple processor cores. The cache 1221 is memory located within the processor chip package and is typically used for data or code that should be available for rapid access by threads or cores running on the processor set 1210. The cache memory is typically organized into multiple levels depending on its relative proximity to the processing circuitry. Alternatively, some or all of the cache for the processor set may be located "off-chip". In some computing environments, the processor set 1210 may operate using qubits and be designed to perform quantum computing.

[0077] Computer-readable program instructions typically cause the processor set 1210 of computer 1201 to execute a series of operational steps, thereby loading them onto computer 1201 to implement a computer implementation method, and the instructions thus executed instantiate the methods specified in the flowcharts and / or descriptions of the computer implementation methods contained herein (collectively referred to as the "Methods of the Invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as the cache 1221 and other storage media discussed below. The program instructions and associated data are accessed by the processor set 1210 to control and direct the execution of the Methods of the Invention. In the computing environment 1200, at least some of the instructions for executing the Methods of the Invention may be stored in block 1250 in persistent storage 1213.

[0078] The communication fabric 1211 is a signal conduction path that enables various components of the computer 1201 to communicate with one another. Typically, this fabric is made up of switches and conductive paths, such as buses, bridges, physical input / output ports, and similar components. Other types of signal communication paths may be used, such as fiber optic communication paths and / or wireless communication paths.

[0079] Volatile memory 1212 is any type of volatile memory currently known or to be developed in the future. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, volatile memory 1212 is characterized by random access, but this is not required unless explicitly stated. In computer 1201, volatile memory 1212 is located in a single package and resides inside computer 1201, but alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally to computer 1201.

[0080] The persistent storage 1213 is any form of non-volatile storage for a computer, currently known or to be developed in the future. The non-volatility of this storage means that the stored data is maintained whether or not power is directly supplied to the computer 1201 and / or the persistent storage 1213. The persistent storage 1213 may be read-only memory (ROM), but typically at least a portion of the persistent storage allows for writing, deleting, and rewriting of data. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. The operating system 1222 may take several forms, such as various known proprietary operating systems or open-source portable operating system interface (CSI) type operating systems employing a kernel. The code contained in block 1250 typically includes at least a portion of computer code involved in performing the method of the present invention.

[0081] The peripheral device set 1214 includes a set of peripheral devices for the computer 1201. Data communication connections between the computer 1201's peripheral devices and other components may be implemented in various ways, such as Bluetooth® connection, Near-Field Communication (NFC) connection, cable connection (such as a universal serial bus (USB) type cable), insertable connection (e.g., a secure digital (SD) card), connection via a local area communication network, and even connection via a wide area network such as the Internet. In various embodiments, the UI device set 1223 may include components such as a display screen, speaker, microphone, wearable device (such as goggles and smartwatches), keyboard, mouse, printer, touchpad, game controller, and haptic device. Storage 1224 is external storage such as an external hard drive, or insertable storage such as an SD card. Storage 1224 may be persistent and / or volatile. In some embodiments, storage 1224 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 1201 is required to have a large amount of storage (for example, when computer 1201 locally stores and manages a large database), this storage may be provided by peripheral storage devices designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The I / OT sensor set 1225 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another may be a motion detector.

[0082] The network module 1215 is a collection of computer software, hardware, and firmware that enables computer 1201 to communicate with other computers via the WAN 1202. The network module 1215 may include hardware such as a modem or Wi-Fi® signal transceiver, software for packetizing and / or depacketizing data for transmission over a communication network, and / or web browser software for communicating data over the internet. In some embodiments, the network control and network forwarding functions of the network module 1215 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN)), the control and forwarding functions of the network module 1215 are performed on physically separate devices, such that the control function manages several different network hardware devices. Computer-readable program instructions for performing the methods of the present invention can typically be downloaded from an external computer or external storage device to computer 1201 through a network adapter card or network interface included in the network module 1215.

[0083] WAN1202 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances by any currently known or future-developed technology for transmitting computer data. In some embodiments, WAN1202 may be replaced and / or supplemented by a local area network (LAN), such as a Wi-Fi network, designed to transmit data between devices located in a local area. WANs and / or LANs typically include computer hardware such as copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0084] The end-user device (EUD) 1203 is any computer system used and controlled by an end-user (e.g., a customer of the company operating computer 1201) and can take any of the forms discussed above in relation to computer 1201. Typically, EUD 1203 receives useful and valuable data from the operation of computer 1201. For example, in a hypothetical case where computer 1201 is designed to provide recommendations to the end-user, these recommendations would typically be communicated from the network module 1215 of computer 1201 to EUD 1203 via WAN 1202. In this way, EUD 1203 can display or otherwise present the recommendations to the end-user. In some embodiments, EUD 1203 may be a client device such as a thin client, heavy client, mainframe computer, or desktop computer.

[0085] The remote server 1204 is any computer system that provides at least some data and / or functionality to computer 1201. The remote server 1204 may be controlled and used by the same entity that operates computer 1201. The remote server 1204 represents a machine that collects and stores useful and valuable data for use by other computers, such as computer 1201. For example, in the hypothetical case where computer 1201 is designed and programmed to provide recommendations based on historical data, this historical data may be provided to computer 1201 from the remote database 1230 of the remote server 1204.

[0086] Public Cloud 1205 is any computer system available for use by multiple entities, providing on-demand availability of computer system resources and / or other computing capabilities, particularly data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct active management of the computing resources of Public Cloud 1205 is performed by the computer hardware and / or software of the Cloud Orchestration Module 1241. The computing resources provided by Public Cloud 1205 are typically implemented by virtual computing environments running on various computers that make up the computers of the host physical machine set 1242, which is the area of ​​physical computers available in and / or to Public Cloud 1205. The virtual computing environment (VCE) typically takes the form of virtual machines from the virtual machine set 1243 and / or containers from the container set 1244. These VCEs may be stored as images and are understood to be transferable either as images or after VCE instantiation, among and between various physical machine hosts. The cloud orchestration module 1241 manages the transfer and storage of images, deploys new VCE instantiations, and manages active instantiations of VCE deployments. The gateway 1240 is a collection of computer software, hardware, and firmware that enables the public cloud 1205 to communicate over the WAN 1202.

[0087] Here, some further explanation of virtualized computing environments (VCEs) is provided. A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from an image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature in the kernel that allows for the existence of multiple isolated user-space instances called containers. These isolated user-space instances typically behave as actual computers from the perspective of the programs running in them. Computer programs running on a normal operating system can utilize all of that computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and the devices allocated to the container; this feature is known as containerization.

[0088] Private Cloud 1206 is similar to Public Cloud 1205, except that its computing resources are available only for use by a single enterprise. While Private Cloud 1206 is shown communicating with WAN 1202, in other embodiments, the private cloud may be completely isolated from the internet and accessible only via a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. Each of the multiple clouds remains a distinct and isolated entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple configuration clouds. In this embodiment, both Public Cloud 1205 and Private Cloud 1206 are part of a larger hybrid cloud.

[0089] A character specifier such as 'i' used to indicate the number of instances of an element may, when used with the same or different elements, indicate a variable of instances of that element.

[0090] The terms “an embodiment,” “embodiment,” “multiple embodiments,” “the embodiment,” “the embodiments,” “one or more embodiments,” “some embodiments,” and “one embodiment” all mean “one or more (but not all) embodiments of the present invention,” unless otherwise explicitly specified.

[0091] The terms “including,” “equipped with,” “having,” or variations thereof, mean “including, but not limited to,” unless explicitly specified otherwise.

[0092] The listed elements do not imply that any or all of them are mutually exclusive unless explicitly stated otherwise.

[0093] The singular forms "a," "an," and "the" mean "one or more" unless explicitly stated otherwise.

[0094] Devices communicating with each other are not necessarily communicating continuously unless explicitly specified otherwise. In addition, devices communicating with each other may communicate directly or indirectly through one or more intermediaries.

[0095] The description of embodiments having several components communicating with each other does not imply that all of these components are necessary. In contrast, various optional components are described to illustrate a wide range of possible embodiments of the invention.

[0096] Where a single device or article is described herein, it will be readily apparent that one or more devices / articles (whether they work together or not) may be used in place of the single device / article. Similarly, where one or more devices or articles (whether they work together or not) are described herein, it will be readily apparent that a single device / article may be used in place of the one or more devices or articles, or that a different number of devices / articles may be used in place of the number of devices or programs indicated. The functions and / or features of a device may be embodied by one or more other devices not expressly described as having such functions / features. Thus, other embodiments of the present invention do not need to include the device itself.

[0097] The above description of various embodiments of the present invention has been presented for illustrative and illustrative purposes only. It is not intended to be exhaustive or to limit the invention to any specific form disclosed. Many modifications and variations are possible in light of the above teachings. The scope of the present invention is intended to be limited not by this detailed description but by the claims attached thereto. The above specifications, examples, and data provide a complete description of the manufacture and use of the configuration of the present invention. Since numerous embodiments of the present invention are possible without departing from the spirit and scope of the invention, the present invention is limited to the claims attached below.

Claims

1. The stage of defining and extracting entities from a database based on semantic information via a Large-Scale Language Model (LLM); The stage of generating data for structured query language (SQL) generation to be incorporated into a multi-layer semantic routable graph; and The step of determining the nodes related to user queries based on the aforementioned multi-layer semantic routable graph. A method that includes [a certain feature].

2. The method according to claim 1, wherein the LLM is used to construct the multi-layer semantic routable graph based on a table schema, table and column descriptions, and SQL syntax operation commands.

3. The method according to claim 1 or 2, wherein the multilayer semantic routable graph stores the schemas of tables and the relationships between different tables.

4. The method according to claim 1, wherein the LLM is used to extend, refine, and decompose user query tasks.

5. The method according to claim 4, wherein the multi-layer semantic routable graph is used to filter nodes that are strongly related to each query subtask.

6. The aforementioned method: The step of defining a ternary graph that represents the relationships between tables and SQL keywords in order to generate complex SQL. The method according to claim 1 or 2, further comprising:

7. The aforementioned method: This stage involves generating SQL based on the calculated subgraphs and performing dynamic graph scaling for graph exploration to determine the final SQL statement. The method according to claim 1 or 2, further comprising:

8. memory; and A processor coupled to the memory, the processor performs an operation, the operation being: A procedure for defining and extracting entities from a database based on semantic information via a Large-Scale Language Model (LLM); Procedures for generating data for structured query language (SQL) generation to be incorporated into a multi-layer semantic routable graph; and Procedure for determining nodes related to user queries based on the aforementioned multi-layer semantic routable graph. including A system that includes these features.

9. The system according to claim 8, wherein the LLM is used to construct the multi-layer semantic routable graph based on table schemas, table and column descriptions, and SQL syntax operation commands.

10. The system according to claim 8 or 9, wherein the multilayer semantic routable graph stores the schemas of tables and the relationships between different tables.

11. The system according to claim 8 or 9, wherein the LLM is used to extend, refine, and decompose user query tasks.

12. The system according to claim 11, wherein the multi-layer semantic routable graph is used to filter nodes that are strongly related to each query subtask.

13. The aforementioned operation is: Steps to define a ternary graph that represents the relationships between tables and SQL keywords in order to generate complex SQL. The system according to claim 8 or 9, further comprising:

14. The aforementioned operation is: The procedure involves generating SQL based on the calculated subgraphs and performing dynamic graph scaling for graph exploration to determine the final SQL statement. The system according to claim 8 or 9, further comprising:

15. To the processor: A procedure for defining and extracting entities from a database based on semantic information via a Large-Scale Language Model (LLM); Procedures for generating data for structured query language (SQL) generation to be incorporated into a multi-layer semantic routable graph; and Procedure for determining nodes related to user queries based on the aforementioned multi-layer semantic routable graph. A computer program designed to execute something.

16. The computer program according to claim 15, wherein the LLM is used to construct the multi-layer semantic routable graph based on a table schema, table and column descriptions, and SQL syntax operation commands.

17. The computer program according to claim 15 or 16, wherein the multilayer semantic routable graph stores the schemas of tables and the relationships between different tables.

18. The LLM is a computer program according to claim 15 or 16, which is used to extend, refine, and decompose user query tasks.

19. The computer program according to claim 18, wherein the multi-layer semantic routable graph is used to filter nodes that are strongly related to each query subtask.

20. To the aforementioned processor: Steps to define a ternary graph that represents the relationships between tables and SQL keywords in order to generate complex SQL. A computer program according to claim 15 or 16 for further execution of the above.

Images