Multi-agent cooperative data query method and device

Abstract

The application provides a multi-agent cooperative data query method and device; the method comprises the following steps: splitting a data query task to obtain a plurality of sub data query tasks of the data query task; determining a target data query service corresponding to a sub data query task from a plurality of data query services, and determining a target data interface service corresponding to the sub data query task from a plurality of data interface services corresponding to the target data query service; and determining a target data interface corresponding to the sub data query task from a plurality of data interfaces corresponding to the target data interface service; executing each target data interface corresponding sub data query task through each sub data query task corresponding target data interface to obtain a sub data query result corresponding to each sub data query task; and fusing the sub data query results corresponding to the plurality of sub data query tasks to obtain a data query result. Through the application, the data query efficiency can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data query method and apparatus for multi-agent collaborative operation. Background Technology

[0002] Data querying refers to the process of retrieving specific information from a database or other data storage system. It is typically implemented using a specific query language (such as SQL, GraphQL, etc.). The functions of data querying include: data retrieval: extracting the desired information from large amounts of data; data analysis: supporting the statistics, analysis, and reporting of data; and decision support: providing data support for business decisions.

[0003] In related technologies, data querying typically involves executing data query tasks separately on each of multiple data interfaces, and then merging the query results from each interface performing the same data query task to obtain the final query result. However, as the volume of queried data increases, this querying method places a heavy query burden on each data interface, resulting in low data query efficiency. Summary of the Invention

[0004] This application provides a multi-agent collaborative data query method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can effectively improve data query efficiency.

[0005] The technical solution of this application embodiment is implemented as follows:

[0006] This application provides a multi-agent collaborative data query method, including:

[0007] In response to a received data query instruction, a data query task corresponding to the data query instruction is constructed, and the data query task is split into multiple sub-data query tasks.

[0008] For each of the sub-data query tasks, based on the first scheduling model, the target selection service for the sub-data query task is determined from the selection services of multiple intelligent agents;

[0009] For each sub-data query task, based on the second scheduling model, a target data query service corresponding to the sub-data query task is determined from multiple data query services corresponding to the target selection service of the sub-data query task. Then, based on the target data query service, a target data interface service corresponding to the sub-data query task is determined from multiple data interface services corresponding to the target data query service, using the third scheduling model. Finally, based on the target data interface service, a target data interface corresponding to the sub-data query task is determined from multiple data interfaces corresponding to the target data interface service, using the fourth scheduling model.

[0010] By executing the target data interface corresponding to each of the sub-data query tasks, the sub-data query task corresponding to each target data interface is obtained, and the sub-data query result corresponding to each sub-data query task is obtained.

[0011] The sub-data query results corresponding to multiple sub-data query tasks are merged to obtain the data query result.

[0012] This application provides a multi-agent collaborative data query device, including:

[0013] The splitting module is used to respond to the received data query instruction, construct the data query task corresponding to the data query instruction, and split the data query task to obtain multiple sub-data query tasks of the data query task; for each sub-data query task, based on the first scheduling model, the target selection service of the sub-data query task is determined from multiple intelligent agent selection services;

[0014] The scheduling module is configured to, for each sub-data query task, determine the target data query service corresponding to the sub-data query task from multiple data query services corresponding to the target selection service of the sub-data query task based on a second scheduling model; and, through the target data query service, determine the target data interface service corresponding to the sub-data query task from multiple data interface services corresponding to the target data query service based on a third scheduling model; and, through the target data interface service, determine the target data interface corresponding to the sub-data query task from multiple data interfaces corresponding to the target data interface service based on a fourth scheduling model.

[0015] The query module is used to execute the sub-data query task corresponding to each target data interface through the target data interface corresponding to each sub-data query task, and obtain the sub-data query result corresponding to each sub-data query task.

[0016] The fusion module is used to merge the sub-data query results corresponding to multiple sub-data query tasks to obtain the data query result.

[0017] This application provides an electronic device, including:

[0018] Memory is used to store executable instructions or computer programs.

[0019] The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the multi-agent collaborative data query method provided in the embodiments of this application.

[0020] This application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the multi-agent collaborative data query method provided in this application.

[0021] This application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the multi-agent collaborative data query method described in this application embodiment.

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

[0023] In response to data query commands, the complex data query task is broken down into multiple subtasks based on the first scheduling model. By analyzing the complexity and resource requirements of the tasks, the task scale is rationally allocated, enabling each subtask to execute independently and providing a foundation for parallel processing. Next, for each subtask, the second scheduling model selects the most suitable service from multiple data query services. This selection is based on factors such as service load, performance, and availability, ensuring efficient resource utilization. The third scheduling model further refines the selection process, determining the target data interface service for each subtask from multiple data interface services corresponding to the target data query service. The fourth scheduling model selects the most suitable interface from multiple specific data interfaces corresponding to the target data interface service to execute the subtask. This process ensures that each subtask can execute efficiently on the most suitable data interface. Through this layered and refined scheduling process, each subtask can execute in an optimized environment, generating sub-data query results. These results are then fused to obtain the complete data query result. This hierarchical scheduling mechanism not only optimizes resource allocation and improves the success rate of task execution but also significantly reduces query time through parallel processing, thereby significantly improving overall data query efficiency. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the architecture of the data query system provided in the embodiments of this application;

[0025] Figure 2 This is a schematic diagram of the structure of an electronic device for data querying provided in an embodiment of this application;

[0026] Figure 3 This is a flowchart illustrating the multi-agent collaborative data query method provided in the embodiments of this application. Figure 1 ;

[0027] Figure 4 This is a flowchart illustrating the multi-agent collaborative data query method provided in the embodiments of this application. Figure 2 ;

[0028] Figure 5 This is a flowchart illustrating the multi-agent collaborative data query method provided in the embodiments of this application. Figure 3 ;

[0029] Figure 6 This is a schematic diagram of the principle of the multi-agent collaborative data query method provided in the embodiments of this application. Figure 1 ;

[0030] Figure 7 This is a schematic diagram of the principle of the multi-agent collaborative data query method provided in the embodiments of this application. Figure 2 . Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0032] In the following description, references are made to "some embodiments," which describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0033] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

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

[0035] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0036] 1) Data Query: This refers to the process of retrieving specific information from a database or other data storage system. It is typically implemented using a specific query language (such as SQL, GraphQL, etc.). The functions of data query include: Data Retrieval: Extracting the required information from large amounts of data; Data Analysis: Supporting the statistics, analysis, and reporting of data; Decision Support: Providing data support for business decisions.

[0037] 2) Database: A database is an organized collection of data, typically stored electronically in a computer system. It supports the storage, retrieval, management, and updating of data. Relational databases, such as MySQL, PostgreSQL, and Oracle, use a tabular structure to store data. Non-relational databases, such as MongoDB (document database), Redis (key-value store), and Cassandra (column store).

[0038] 3) Large Language Model (LLM): A large language model is a deep learning-based artificial intelligence model that typically has billions or even hundreds of billions of parameters and is capable of generating natural language text. These models are trained on massive amounts of text data to learn language patterns and structures.

[0039] 4) Data Interface: A data interface is an interface that allows data exchange between different systems or components. It defines the data format, transmission method, and operation rules. API (Application Programming Interface): Such as REST API and GraphQL API, used for data exchange between applications. Database Interface: Such as JDBC (Java Database Connectivity) and ODBC (Open Database Connectivity), used for interaction between applications and databases.

[0040] 5) The Model Context Protocol (MCP) is a communication protocol for standardizing tool calls and agent collaboration. It allows models to dynamically access external APIs or database tools during inference while maintaining context consistency. MCP defines a standardized way for models to call external tools, which can be APIs, databases, or other services. Through standardized calls, models can interact with external systems more flexibly. During inference, models need to maintain context consistency. MCP ensures, through its protocol mechanism, that models correctly transmit and maintain context information when calling external tools. This helps models maintain the coherence and accuracy of inference in complex tasks. MCP supports models dynamically accessing external tools during inference. This means that models can call the necessary tools in real time based on the current inference state, without needing to predefine all tool calls at the start of inference. In multi-agent systems, multiple models need to collaborate. MCP provides a mechanism that allows these models to interact through a standardized communication protocol, thereby achieving efficient collaborative work.

[0041] 6) Agent: An agent is an intelligent module capable of autonomously completing specific tasks, typically possessing state awareness, decision-making and planning capabilities, and tool invocation abilities. Agents can form multi-agent systems with other agents to collaboratively complete complex tasks. Agents are able to perceive the state of their environment. This means that agents can collect and understand information from the environment to make appropriate decisions. State awareness enables agents to respond to environmental changes in real time, ensuring the adaptability and effectiveness of their behavior. Agents can formulate decisions and plan based on perceived state information. This includes selecting the optimal action path, allocating resources, and adjusting strategies. Decision-making and planning capabilities enable agents to effectively solve complex problems and achieve goals.

[0042] 7) A2A (Agent-to-Agent Protocol): This protocol is an open standard initiated by Google, designed to enable communication and interoperability between different AI agent systems. The core objective of the A2A protocol is to break down barriers between different AI agents, enabling them to communicate and collaborate effectively in a dynamic multi-agent ecosystem. It allows AI agents to collaborate when completing complex tasks; for example, one agent can delegate a subtask to another.

[0043] 8) NL2SQL (Natural Language to SQL): This refers to the technology that automatically translates human natural language input into executable database query statements. It is a key capability commonly used in intelligent question-answering systems, capable of converting users' natural language questions into structured SQL query statements to retrieve relevant information from the database. The main goal of NL2SQL is to enable users to query databases in natural language without writing complex SQL statements. This significantly lowers the barrier to database queries, improves user experience, and allows non-technical users to easily access data. An NL2SQL system needs to understand the user's natural language input, including the intent and key information of the question. It then converts the understood natural language question into a structured SQL query statement. The generated SQL query statement is sent to the database for execution and the query results are returned. Finally, the query results are presented in a user-friendly manner, such as in the form of tables or charts.

[0044] During the implementation of the embodiments of this application, the applicant discovered the following problems with the related technology:

[0045] In related technologies, data querying typically involves executing data query tasks separately on each of multiple data interfaces, and then merging the query results from each interface performing the same data query task to obtain the final query result. However, as the volume of queried data increases, this querying method places a heavy query burden on each data interface, resulting in low data query efficiency.

[0046] This application provides a multi-agent collaborative data query method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can effectively improve data query efficiency. The following describes an exemplary application of the data query system provided in this application.

[0047] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of the data query system 100 provided in the embodiments of this application. The terminal (terminal 400 is shown as an example) connects to the server 200 through the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0048] Terminal 400 is used by users to access client 410 and display data query results on a graphical interface 410-1 (graphical interface 410-1 is shown as an example). Terminal 400 and server 200 are interconnected via wired or wireless network.

[0049] In some embodiments, server 200 can be a standalone physical server, a server cluster or business system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Terminal 400 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smart TV, smartwatch, in-vehicle terminal, etc., but is not limited to these. The electronic device provided in this application embodiment can be implemented as a terminal or a server. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited in this application embodiment.

[0050] See Figure 2 , Figure 2 This is a schematic diagram of the structure of an electronic device 500 for data querying provided in an embodiment of this application, wherein, Figure 2 The electronic device 500 shown can be Figure 1 Server 200 or terminal 400 in the middle, Figure 2 The illustrated electronic device 500 includes at least one processor 430, a memory 450, and at least one network interface 420. The various components in the electronic device 500 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 440.

[0051] Processor 430 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0052] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 430.

[0053] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0054] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0055] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0056] The network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420, such as Bluetooth, WiFi, and Universal Serial Bus.

[0057] In some embodiments, the multi-agent collaborative data query device provided in this application can be implemented in software. Figure 2 A multi-agent collaborative data query device 455 stored in memory 450 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a splitting module 4551, a scheduling module 4552, a querying module 4553, and a fusion module 4554. These modules are logically connected and can therefore be arbitrarily combined or further split according to their implemented functions. The functions of each module will be described below.

[0058] In other embodiments, the multi-agent collaborative data query device provided in this application can be implemented in hardware. As an example, the multi-agent collaborative data query device provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the multi-agent collaborative data query method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0059] In some embodiments, the terminal or server can implement the multi-agent collaborative data query method provided in this application by running a computer program or computer-executable instructions. For example, the computer program can be a native program in the operating system (e.g., a dedicated data query program) or a software module, such as a data query module that can be embedded in any program (e.g., an instant messaging client, a photo album program, an electronic map client, a navigation client); or it can be a native application (APP), i.e., a program that needs to be installed in the operating system to run. In summary, the above-mentioned computer program can be any form of application, module, or plugin.

[0060] The data query method for multi-agent collaboration provided in this application will be described by combining exemplary applications and implementations of the server or terminal provided in the embodiments of this application.

[0061] See Figure 3 , Figure 3 This is a flowchart illustrating the multi-agent collaborative data query method provided in the embodiments of this application. Figure 1 , will combine Figure 3 Steps 101 to 108 are described below. The multi-agent collaborative data query method provided in this application embodiment can be implemented by the server or terminal alone, or by the server and terminal in collaboration. The following description will take the implementation by the server alone as an example.

[0062] In step 101, in response to the received data query instruction, a data query task corresponding to the data query instruction is constructed.

[0063] In some embodiments, a data query instruction refers to a request issued by a user or system to query specific data or information. It typically includes query parameters, conditions, and a target data source. Sources of data query instructions include: User input: Users enter query requests through an interface (such as a webpage or application), for example, entering keywords in a search engine. System calls: Query requests issued by other modules or services within the system, such as query operations in a database management system.

[0064] In some embodiments, a data query instruction refers to a request issued by a user or system that contains natural language semantics. Its characteristics include: semantic input: the user's query intent expressed in natural language (e.g., "query the operational risks of a company over the past three years"). In the context of big data, users cannot know what query information and intent will accurately hit fields in the database. The multi-layered retrieval and multi-layered scheduling process in this application is precisely the process of hierarchically parsing such ambiguous query intents to improve the hit rate. A data query instruction refers to the user's query intent expressed in natural language, rather than directly using structured query statements. This query method is more intuitive and natural, suitable for non-technical users. In a big data environment, users often find it difficult to precisely specify query conditions. Therefore, the system adopts a multi-layered retrieval and multi-layered scheduling process to gradually parse the user's query intent, generate precise query statements, and thus improve the query hit rate. This not only improves the user experience but also enhances the system's flexibility and adaptability. A data query instruction refers to a request issued by a user or system that contains natural language semantics, used to retrieve information from the database. The characteristic of this instruction is that the user expresses their query intent in natural language, rather than directly using structured query statements (such as SQL).

[0065] In some embodiments, the data query instruction carries at least one query statement, and step 101 above can be implemented as follows: for each query statement, query an index entry containing the query statement from a preset statement-execution logic mapping relationship, and determine the execution logic in the index entry as the target execution logic corresponding to the query statement; generate a data query task corresponding to the data query instruction based on the target execution logic corresponding to each query statement through a task construction model.

[0066] In some embodiments, the query statement carried in a data query instruction refers to a specific query request, typically expressed in a query language (such as SQL, GraphQL, etc.). Each query statement contains specific query parameters and conditions.

[0067] As an example, query statement 1: SELECT * FROM table1 WHERE condition1; query statement 2: SELECT * FROM table2 WHERE condition2.

[0068] In some embodiments, the statement-execution logic mapping is a pre-defined mapping table used to map query statements to specific execution logic. This mapping is typically predefined by the system to facilitate quick matching of query statements and execution logic.

[0069] As an example, an index entry: Each query statement has a corresponding index entry in the mapping relationship. This entry contains the identifier of the query statement and the corresponding execution logic. Execution logic: The execution logic in each index entry defines how to execute the query statement, including the data source, query path, result processing, etc.

[0070] In some embodiments, index entries are queried and target execution logic is determined. For each query statement: each query statement in the data query instruction is processed one by one. From the preset statement-execution logic mapping relationship, the index entry containing the query statement is searched. The execution logic in the found index entry is determined as the target execution logic corresponding to the query statement.

[0071] As an example, query 1: SELECT * FROM table1 WHERE condition1; index entry 1: {"query": "SELECT * FROM table1 WHERE condition1", "executionLogic": "Logic1"}; target execution logic 1: Logic1. Query 2: SELECT * FROM table2 WHERE condition2; index entry 2: {"query": "SELECT * FROM table2 WHERE condition2", "executionLogic": "Logic2"}; target execution logic 2: Logic2.

[0072] In some embodiments, the task building model is used to generate a complete data query task based on the target execution logic. The task building model receives the target execution logic corresponding to each query statement. The target execution logic is encapsulated into an executable data query task, including query parameters, data source information, result processing logic, etc.

[0073] As an example, the target execution logic of query statement 1 is Logic1; the generated task 1 is: {"query": "SELECT * FROM table1 WHERE condition1", "dataSource": "table1", "executionLogic": "Logic1"}; the target execution logic of query statement 2 is Logic2; the generated task 2 is: {"query": "SELECT * FROM table2 WHERE condition2", "dataSource": "table2", "executionLogic": "Logic2"}.

[0074] In some embodiments, the task construction model includes: a logic parsing unit, used to parse the target execution logic and extract key information from the execution logic; a data source binding unit, used to bind relevant data source information according to the query statement and the target execution logic; and a task generation unit, used to encapsulate the query statement, the target execution logic, and the data source information into the data query task.

[0075] In some embodiments, the logic parsing unit parses the target execution logic and extracts key information from the execution logic, such as the query path, query operation, and result processing logic. The data source binding unit binds relevant data source information based on the query statement and the target execution logic, determining from which data source to obtain the data. The task generation unit encapsulates the query statement, target execution logic, and data source information into the data query task. The data query task also includes query result formatting settings for outputting the query results according to a preset format. The task construction model ultimately generates the data query task corresponding to the data query instruction. The data query task includes a query statement, target execution logic, and data source information related to the query statement, ensuring the completeness and executability of the task.

[0076] Thus, for each query statement, the system retrieves the corresponding index entry from the pre-defined statement-execution logic mapping relationship. This process, based on the pre-defined mapping relationship, can quickly locate the execution logic of each query statement, avoiding complex real-time parsing and logical derivation, thereby significantly reducing the time complexity of query statement processing. By identifying the execution logic in the index entries as the target execution logic, the system can accurately assign an appropriate execution strategy to each query statement. Subsequently, the task building model generates data query tasks based on these target execution logics. The introduction of the task building model enables the system to effectively integrate the logic of the query statement with actual data source information, query parameters, etc., generating structured and executable data query tasks. This not only improves the efficiency of task generation but also ensures the accuracy and consistency of the generated tasks through pre-defined mapping relationships and modeling processing.

[0077] In step 102, the data query task is split into multiple sub-data query tasks.

[0078] In some embodiments, a data query task refers to a query operation that the system needs to perform, typically involving retrieving data from a database or other data source. A query task may contain multiple query statements, involve multiple data sources, or have complex query logic. For large datasets or complex query logic, a single query task may require significant computational resources and time to complete. Therefore, breaking down a query task into multiple subtasks can improve execution efficiency and system scalability.

[0079] In some embodiments, the first scheduling model is a pre-defined algorithm or rule set used to determine how to break down a data query task into multiple subtasks. The scheduling model typically considers factors such as task complexity, data source distribution, and resource availability. By rationally allocating subtasks to different resources (such as CPU, memory, and network bandwidth), resource utilization is improved. The system load is ensured to be evenly distributed, avoiding overload of some resources while others remain idle. Multiple subtasks are allowed to execute simultaneously, thereby shortening the overall query time.

[0080] In some embodiments, it is necessary to analyze the structure and requirements of the original data query task. This includes identifying the query statement, data source, query logic, etc. According to the rules of the first scheduling model, the data query task is broken down into multiple subtasks. The scheduling model may consider the following factors: Query statement complexity: breaking complex queries into multiple simpler subqueries. Data source distribution: breaking query tasks involving multiple data sources into subtasks for each data source. Resource availability: allocating the number and size of subtasks reasonably based on the system's resource status. Each subtask is an independent query task, containing part of the logic and data source information of the original query task. Subtasks can be executed in parallel or sequentially, depending on the design of the scheduling model.

[0081] In some embodiments, see Figure 4 , Figure 4 This is a flowchart illustrating the multi-agent collaborative data query method provided in the embodiments of this application. Figure 2 , Figure 3 Step 102 shown can be achieved through Figure 4 Steps 1021 to 1023 shown are implemented.

[0082] In step 1021, based on the data query instruction, a first number of the plurality of sub-data query tasks is predicted, and a first probability for indicating that the data query task can be executed is determined.

[0083] In some embodiments, a data query task refers to a query operation that the system needs to perform, typically involving retrieving data from a database or other data source. A query task may contain multiple query statements, involve multiple data sources, or complex query logic. For large datasets or complex query logic, a single query task may require significant computational resources and time to complete. Therefore, breaking down a query task into multiple subtasks can improve execution efficiency and system scalability. A first scheduling model is a pre-defined algorithm or set of rules used to determine how to break down a data query task into multiple subtasks. The scheduling model typically considers factors such as task complexity, data source distribution, and resource availability. It improves resource utilization by rationally allocating subtasks to different resources (such as CPU, memory, and network bandwidth). It ensures a uniform distribution of system load, avoiding overload of some resources while others remain idle. It allows multiple subtasks to execute simultaneously, thereby shortening the overall query time. It requires analyzing the structure and requirements of the original data query task. This includes identifying query statements, data sources, query logic, etc. Based on the rules of the first scheduling model, the data query task is broken down into multiple subtasks. The scheduling model may consider the following factors: Query statement complexity: breaking down complex query statements into multiple simpler subqueries. Data source distribution: Query tasks involving multiple data sources are broken down into subtasks targeting each data source. Resource availability: The number and size of subtasks are allocated appropriately based on the system's resource availability. Each subtask is an independent query task, containing some of the logic from the original query task and data source information. Subtasks can be executed in parallel or sequentially, depending on the scheduling model design.

[0084] In some embodiments, the probability of a data query task successfully executing is predicted based on the complexity of the data query instruction and the rules of the scheduling model. Historical data analysis: Analyzing historical execution data to understand the success rate of similar query tasks. Resource assessment: Assessing the current system resource status, including CPU, memory, network bandwidth, etc. Complexity assessment: Assessing the difficulty of task execution based on the complexity of the query statement. Applying the scheduling model: Based on the rules of the first scheduling model and considering the above factors comprehensively, the probability of task successful execution is predicted.

[0085] As an example, the query instruction involves two tables: table1 and table2. The query logic includes a join query and conditional filtering. Complexity assessment: The query involves two data sources and includes join query logic. Scheduling model application: Based on the rules of the first scheduling model, it is predicted that the query task will be split into two subtasks: Subtask 1: Retrieve data that meets the conditions from table1. Subtask 2: Retrieve data that meets the conditions from table2. Prediction result: The predicted number of subtasks is 2. Historical data analysis: Analyzing historical execution data reveals that the success rate of similar query tasks is 90%. Resource assessment: Current system resources are sufficient, with low CPU and memory usage. Complexity assessment: The query logic is complex, but the system resources are sufficient to handle it. Scheduling model application: Considering the above factors, the predicted probability of task execution success is 85%.

[0086] In some embodiments, the first scheduling model includes a feature extraction layer, a first prediction layer, and a second prediction layer. Step 1021 can be implemented as follows: the feature extraction layer extracts features from the data query instruction to obtain query instruction features; the first prediction layer predicts a first number of the plurality of sub-data query tasks based on the query instruction features; and the second prediction layer predicts a first probability for indicating that the data query task can be executed based on the query instruction features.

[0087] In some embodiments, the structure of the first scheduling model includes: a feature extraction layer responsible for extracting key features from data query instructions, such as the structure of the query statement, data source type, historical execution time, etc.; a first prediction layer that predicts the number of subtasks after the data query task is broken down based on the extracted features; and a second prediction layer that predicts the probability of the data query task being executed successfully based on the extracted features.

[0088] In some embodiments, feature extraction extracts information useful for prediction from data query instructions. This information may include the length of the query statement, the number of data sources involved, historical execution times, etc. The extracted features are used in subsequent prediction layers to help the model make more accurate predictions. The first prediction layer is a prediction model used to predict the number of subtasks after the data query task is broken down. Input: Query instruction features extracted by the feature extraction layer. Output: The predicted number of subtasks. Implementation: The first prediction layer can be implemented using machine learning algorithms (such as linear regression, decision trees, neural networks, etc.).

[0089] In some embodiments, the second prediction layer is a prediction model used to predict the probability of a data query task being executed successfully. Input: Query instruction features extracted by the feature extraction layer. Output: The predicted execution probability. Implementation: The second prediction layer can be implemented using machine learning algorithms (such as logistic regression, random forest, deep learning, etc.).

[0090] In some embodiments, data query instructions are analyzed to extract features such as the structure of the query statement, the type of data source, and historical execution time. For example, for the query statement SELECT * FROM table1 WHERE condition1, the extracted features may include: the amount of data in table1, the complexity of condition1, etc.

[0091] In some embodiments, the extracted features are input into the model of the first prediction layer. The model predicts the number of subtasks after the data query task is broken down based on the relationship between historical data and the features. For example, if historical data shows that similar queries are typically broken down into 3 subtasks, the model will predict that the number of subtasks is 3.

[0092] In some embodiments, the extracted features are input into the model of the second prediction layer. Based on the relationship between historical data and the features, the model predicts the probability of a successful data query task. For example, if historical data shows a 90% success rate for similar queries, the model will predict a 90% success rate.

[0093] As an example, in a large e-commerce platform, users can query order information through the system. Due to the massive and complex volume of order data, the query task may involve multiple database tables (such as the order table, user table, product table, etc.) and may require complex join queries. To optimize query performance, the system needs to predict the complexity of the query task (such as the number of subtasks) and the probability of successful execution before executing the query task. The feature extraction layer takes the following inputs as: the order query command submitted by the user, for example: "Query the order information of all goods purchased by user A in the past month". Feature extraction includes: Query statement structure: Extracting the structural features of the query statement, such as whether it involves join queries, whether it includes time range filtering, etc. Data source information: Identifying the data sources involved in the query, such as the order table, user table, product table, etc. Historical execution data: Extracting information such as the execution time and resource consumption of similar queries based on historical query records. User behavior features: Analyzing user A's historical query behavior, such as query frequency and query time range. Output: Obtaining a set of query command features, such as: Query statement structure features: including join queries and time range filtering. Data source information: involving the order table, user table, and product table. Historical execution time: The average execution time is 2 seconds. User behavior characteristics: User A queries orders 3 times per month.

[0094] Continuing the previous example, the first prediction layer takes the following input: a set of query instruction features obtained from the feature extraction layer. The prediction process involves determining the query's complexity based on its structural features. For example, join queries typically need to be broken down into multiple subtasks. It also determines the number of tables involved based on the data source information. For example, a query involving three tables might need to be broken down into three subtasks. The predicted number of subtasks is adjusted by combining historical execution data. For example, if historical data shows that similar queries are typically broken down into four subtasks, the predicted number of subtasks is four. The output is the predicted number of subtasks. For example, the predicted number of subtasks is four. The second prediction layer takes the following input: a set of query instruction features obtained from the feature extraction layer. The prediction process involves determining the query's complexity based on its structural features. For example, complex join queries may reduce the probability of successful execution. It also determines the number of tables and the amount of data involved based on the data source information. For example, queries involving multiple large tables may reduce the probability of successful execution. The probability of successful execution is adjusted by combining historical execution data. For example, if historical data shows that the success rate of similar queries is 85%, the predicted probability of successful execution is 85%. The output is the predicted probability of successful execution. For example, the probability of successful execution is predicted to be 85%.

[0095] As an example, suppose user A submits a query: "Query all order information for goods purchased by user A in the past month." Feature Extraction Layer: Extracted features include: Query structure: Includes a join query (order table and product table), and time range filtering (past month). Data source information: Involves the order table, user table, and product table. Historical execution time: Average execution time is 2 seconds. User behavior characteristics: User A queries orders 3 times per month. First Prediction Layer: Based on the query structure and data source information, the number of subtasks is predicted to be 4: Subtask 1: Extract user A's order information from the order table. Subtask 2: Extract user A's detailed information from the user table. Subtask 3: Extract product information involved in the orders from the product table. Subtask 4: Perform a join query on the results of the above subtasks to generate the final query result. Second Prediction Layer: Based on the query structure, data source information, and historical execution data, the probability of successful execution is predicted to be 85%: The query involves a join query of multiple tables, which is highly complex. Historical data shows that the success rate of similar queries is 85%. The current system resources are sufficient to support the execution of the query.

[0096] Thus, the feature extraction layer analyzes the data query commands and extracts key features that reflect important information such as query complexity, data source distribution, and historical execution status. This provides a data foundation for subsequent predictions, ensuring their accuracy and reliability. Next, the first prediction layer, based on the extracted features, predicts the number of subtasks after the data query task is broken down. By analyzing the relationship between features and the number of subtasks, the model can quickly and accurately estimate the complexity of the task, providing a basis for resource allocation and task scheduling. Simultaneously, the second prediction layer, based on the same features, predicts the probability of successful execution of the data query task. This probabilistic prediction allows the system to assess task feasibility in advance, optimize execution strategies, and avoid resource waste. Through this hierarchical prediction mechanism, the system can not only efficiently handle complex query tasks but also dynamically adjust resource allocation and execution strategies based on prediction results, thereby significantly improving the overall performance and reliability of the system.

[0097] In step 1022, the first probability is compared with the probability threshold to obtain a first comparison result.

[0098] In some embodiments, the first comparison result is used to indicate whether the first probability is greater than the probability threshold. When the first probability is not greater than the probability threshold, a prompt message is output to indicate that the data query failed.

[0099] In some embodiments, the first probability is predicted by the second prediction layer and indicates the probability that the data query task can be successfully executed. It is a value between 0 and 1, representing the likelihood of the task's success. The probability threshold is a preset threshold used to determine whether the probability of the task's success is high enough. The specific value of the threshold can be set according to the actual needs and reliability requirements of the system, for example, 0.5, 0.7, or 0.9. The first comparison result is obtained by comparing the first probability with the probability threshold, resulting in a Boolean value (i.e., "yes" or "no"). If the first probability is greater than the probability threshold, the comparison result is "yes"; otherwise, it is "no".

[0100] In some embodiments, a first probability greater than a probability threshold means that the predictive model believes the data query task has a high probability of successful execution. In this case, the system can continue to execute the query task or further optimize the query strategy to improve execution efficiency. A first probability less than a probability threshold means that the predictive model believes the data query task has a low probability of success. This may be due to the query task being too complex, involving too many data sources, insufficient system resources, or other potential problems.

[0101] In some embodiments, the system outputs a prompt message when the first probability is not greater than a probability threshold, informing the user that the data query task may fail. The prompt message can be text, a warning sign, or other forms of user interface feedback. Its purpose is to inform users in advance that the query task may not be successfully executed, thereby avoiding long waiting times or wasting system resources. Users can adjust query conditions, optimize query statements, or choose other query methods based on the prompt message.

[0102] As an example, suppose a user submits a complex order query request in a large e-commerce system, seeking information on all orders for a specific product made within the past year. The system, through a second prediction layer, predicts a success rate of 0.3 (30%). If the preset probability threshold is 0.5 (50%), then the first probability (0.3) is no greater than the probability threshold (0.5). In this case, the system will output a message such as: "The query task may fail. Please check your query conditions or try again later." This allows the user to know in advance that the query task may fail, thus avoiding a long wait for a resultless query.

[0103] In step 1023, if the first comparison result indicates that the first probability is greater than the probability threshold, then based on the first quantity, the data query task is split into the plurality of sub-data query tasks.

[0104] In some embodiments, if the first probability is greater than a probability threshold, it means that the prediction model considers the data query task to have a high probability of successful execution. This indicates that the complexity and resource requirements of the query task are within the system's processing capacity. In this case, the system can continue to execute the query task and split it into multiple subtasks based on the predicted number of subtasks (the first quantity). The first quantity: This is predicted by the first prediction layer and represents the number of subtasks after the data query task is split. Analyzing the query task: The system first analyzes the structure and requirements of the original data query task, identifying the parts that can be executed independently. Splitting subtasks: Based on the predicted first quantity, the query task is split into multiple subtasks. Each subtask contains part of the logic and data source information of the original query task. Generating subtasks: Each subtask is an independent query task that can be executed in parallel or sequentially. The generation of subtasks ensures the integrity and executability of the task.

[0105] As an example, suppose a user submits a complex order query request on a large e-commerce platform, retrieving order information for all purchases of a specific product within the past year. The system, through its second prediction layer, predicts a success rate of 0.8 (80%) for this query task, with a preset probability threshold of 0.5 (50%). Simultaneously, the system, through its first prediction layer, predicts that this query task can be broken down into four sub-tasks. The first probability (0.8) is greater than the probability threshold (0.5), therefore the first comparison result is "yes". Based on the predicted number (four sub-tasks), the query task is broken down into the following sub-tasks: Sub-task 1: Extract the user's order information from the order table within the past year. Sub-task 2: Extract information about a specific product from the product table. Sub-task 3: Extract detailed user information from the user table. Sub-task 4: Perform a joint query on the results of the above sub-tasks to generate the final query result.

[0106] As an example, for the first scheduler, faced with a user query for "legal risks of a company," and the A2A tools included at that level—"Shell Company Identification System," "Corporate Legal Litigation Analysis System," "Corporate ESG Analyzer," and "Equity Structure Query System"—and a first quantity of 1, it decides to activate the "Corporate Legal Litigation Analysis System" for subsequent tasks. The first scheduling model, based on the query request "legal risks of a company" and an analysis of the functions of each tool, decides to activate the "Corporate Legal Litigation Analysis System." This decision may be based on the tool's expertise and efficiency in handling legal risk-related queries, as well as the high degree of matching between the current query request and the tool's functionality. Simultaneously, considering the first quantity is 1, this may mean that in the current situation, only one tool needs to be activated to meet the query requirement, or that the "Corporate Legal Litigation Analysis System" has the highest priority among all candidate tools. By activating the "Corporate Legal Litigation Analysis System," the first scheduling model can ensure that subsequent tasks are processed more precisely on the "legal risks" aspect that the user is concerned about, thereby providing the user with more targeted and valuable information. This process not only demonstrates the intelligence and flexibility of the first scheduling model in task allocation, but also showcases the efficiency and complementarity of A2A tools in collaborative work.

[0107] In some embodiments, the data query task includes target execution logic carried in the data query instruction for each query statement. The above-mentioned division of the data query task into multiple sub-data query tasks based on the first quantity can be achieved as follows: determine a second quantity of the target execution logic in the data query task, and compare the second quantity with the first quantity to obtain a second comparison result; if the second comparison result indicates that the first quantity is less than or equal to the second quantity, then the data query task is divided into the first quantity of sub-data query tasks; if the second comparison result indicates that the first quantity is greater than the second quantity, then the data query task is divided into the second quantity of sub-data query tasks, each sub-data query task including at least one of the target execution logics.

[0108] In some embodiments, a data query task is a task containing multiple query statements, each with corresponding target execution logic. The target execution logic is obtained from a predefined statement-execution logic mapping and guides the execution of each query statement. A first quantity, predicted by a first prediction layer, represents the number of subtasks the data query task can be divided into. A second quantity, obtained by analyzing the target execution logic within the data query task, represents the actual number of target execution logics. A Boolean result is obtained by comparing the first and second quantities. The comparison result determines how to split the data query task. If the first quantity is less than or equal to the second quantity, the predicted number of subtasks is within the range of the actual target execution logic. Therefore, the data query task can be split according to the predicted first quantity. If the first quantity is greater than the second quantity, the predicted number of subtasks exceeds the actual number of target execution logics. In this case, the data query task should be split according to the actual number of target execution logics. Each subtask contains at least one target execution logic. These subtasks can be executed independently, and the results are merged upon completion.

[0109] As an example, suppose a user submits a data query task containing multiple query statements in a large database system. The system predicts a first quantity of 4 through a first prediction layer and a second quantity of 3 through analysis of the query task. The first quantity (4) is greater than the second quantity (3), therefore the second comparison result indicates that the first quantity is greater than the second quantity. Based on the second comparison result, the data query task is split into subtasks of the second quantity (3). Each subtask contains a target execution logic: Subtask 1: Execute the target execution logic of the first query statement. Subtask 2: Execute the target execution logic of the second query statement. Subtask 3: Execute the target execution logic of the third query statement.

[0110] Thus, the system compares the first quantity (the predicted number of subtasks) obtained from the prediction model with the second quantity (the number of target execution logics) obtained from the actual analysis. This comparison process provides a basis for task splitting decisions, ensuring the rationality of the splitting strategy. When the first quantity is less than or equal to the second quantity, the system splits tasks according to the predicted first quantity, fully utilizing the foresight of the prediction model, allowing task splitting to adapt to changes in system resources and query complexity in advance, thereby optimizing resource allocation and improving query efficiency. When the first quantity is greater than the second quantity, the system splits tasks according to the actual number of target execution logics, avoiding resource waste and increased management overhead caused by over-splitting. By ensuring that each sub-data query task contains at least one target execution logic, this method further guarantees the executability and independence of subtasks, enabling subtasks to be processed in parallel and further improving the system's throughput.

[0111] Thus, the first scheduling model, based on data query instructions, predicts the initial number of multiple sub-data query tasks and the initial probability that each task can be executed. Leveraging the ability to analyze historical data and the current system state, it can quickly assess the feasibility and complexity of the task. By comparing the initial probability with a preset probability threshold, the likelihood of successful task execution can be determined. If the initial probability is greater than the probability threshold, it indicates a high success rate, and the data query task is then divided into multiple sub-tasks based on the predicted initial number. By breaking down complex tasks into multiple sub-tasks, these sub-tasks can be processed in parallel, significantly improving query efficiency and resource utilization.

[0112] In step 103, for each of the sub-data query tasks, based on the first scheduling model, the target selection service for the sub-data query task is determined from multiple intelligent agent selection services.

[0113] In some embodiments of intelligent question-answering systems, especially in scenarios involving multi-agent collaboration, the selection of an Agent-to-Agent (A2A) Server is a crucial step. An A2A Server is an agent that provides specific functions or services, while the A2A Host is the master agent responsible for coordinating and scheduling these services. The role of the first scheduling model is to help the A2A Host select the most suitable service from multiple available A2A Servers to handle the current sub-data query task. An A2A Server is an agent that provides specific functions or services, such as: a shell company identification system (used to identify shell companies); a corporate litigation analysis system (used to analyze a company's legal proceedings); a corporate ESG analyzer (used to analyze a company's environmental, social, and governance (ESG) performance); or an equity structure query system (used to query a company's equity structure). These A2A Servers are tools available in the system, each with its specific functions and applicable scenarios.

[0114] In some embodiments, the first scheduling model is a decision-making mechanism that helps the A2A Host select the most suitable service from multiple available A2A Servers to handle the current sub-data query task. The scheduling model typically considers the following factors: Task requirements: The specific requirements of the sub-data query task, such as the type of query, required data fields, etc. Service capabilities: The functionality and performance of each A2A Server, such as processing speed, accuracy, etc. Resource availability: The load status of each A2A Server in the current system, ensuring that the selected service has sufficient resources to handle the task.

[0115] In some embodiments, for each sub-data query task, the first scheduling model (i.e., the agent described above) performs the following steps to determine the target selection service: Analyze each sub-data query task to extract key information and query intent. For example, for the sub-task "Query the legal litigation records of a company in the past three years," the extracted key information might include "legal litigation," "past three years," and "a company." Evaluate the capabilities of each A2A Server to determine which services can handle the current sub-task. For example, for the sub-task "Query the legal litigation records of a company in the past three years," evaluate which A2A Servers have legal litigation analysis capabilities. Check the current load of each A2A Server to ensure that the selected service has sufficient resources to handle the task. For example, if an A2A Server is currently overloaded, another service with a lower load might be selected. Based on the above evaluation, the first scheduling model decides which A2A Server to route the sub-task to. For example, if the "Enterprise Judicial Litigation Analysis System" can handle the sub-task "Query the legal litigation records of a company in the past three years" and its current load is low, the first scheduling model will route the sub-task to the "Enterprise Judicial Litigation Analysis System."

[0116] As an example, suppose a user's query is "Query the legal risks of a company in the past three years". The system breaks down this query task into the following subtasks: Subtask 1: Query the legal litigation records of a company in the past three years. Subtask 2: Query the compliance records of a company in the past three years. For Subtask 1, "Query the legal litigation records of a company in the past three years": Task Analysis: Extract key information "legal litigation", "past three years", and "a company". Service Assessment: Assess the capabilities of the A2A Server to determine if the "Enterprise Judicial Litigation Analysis System" can handle this subtask. Resource Check: Check the current load of the "Enterprise Judicial Litigation Analysis System" to confirm that it has sufficient resources. Decision: The first scheduling model decides to route Subtask 1 to the "Enterprise Judicial Litigation Analysis System". For Subtask 2, "Query the compliance records of a company in the past three years": Task Analysis: Extract key information "compliance records", "past three years", and "a company". Service Assessment: Assess the capabilities of the A2A Server to determine if the "Enterprise ESG Analyzer" can handle this subtask. Resource Check: Check the current load of the "Enterprise ESG Analyzer" to confirm that it has sufficient resources. Decision: The first scheduling model decides to route subtask 2 to the "Enterprise ESG Analyzer".

[0117] In step 104, for each of the sub-data query tasks, based on the second scheduling model, the target data query service corresponding to the sub-data query task is determined from multiple data query services corresponding to the target selection service of the sub-data query task.

[0118] In some embodiments, a sub-data query task is an independent query task split from a data query task. Each sub-task contains one or more query statements and their corresponding target execution logic. Purpose: By splitting complex data query tasks into multiple sub-tasks, query efficiency can be improved, resource allocation optimized, and parallel processing supported. The second scheduling model is an algorithm or set of rules used to determine how to allocate sub-data query tasks to different data query services. Functions: Resource optimization: Based on the characteristics of the sub-tasks and the system's resource status, tasks are rationally allocated to different services to improve resource utilization. Load balancing: Ensures even distribution of system load, avoiding overload of some services while others are idle. Performance optimization: Selects the most suitable service for executing each sub-task to improve query efficiency. Determine the target data query service.

[0119] In some embodiments, a target data query service is determined. Inputs include: each sub-data query task and its characteristics (e.g., query complexity, data source type, expected execution time, etc.). Processing: Sub-task characteristics are analyzed: The second scheduling model first analyzes the characteristics of each sub-data query task to understand its resource requirements and execution characteristics. Service capabilities are evaluated: Based on the characteristics of the sub-tasks, the capabilities of multiple data query services are evaluated, including service load, performance, availability, etc. Target service is selected: Based on the above evaluation, the most suitable data query service for executing the sub-task is selected. Selection criteria may include: Current service load: Selecting services with lower load to avoid overload. Service performance: Selecting the service with the best performance to improve query efficiency. Service availability: Selecting the service with the highest availability to ensure task reliability. Data source distribution: Selecting services close to the data source to reduce data transfer time and cost. Output: A target data query service is assigned to each sub-data query task.

[0120] In some embodiments, see Figure 5 , Figure 5 This is a flowchart illustrating the multi-agent collaborative data query method provided in the embodiments of this application. Figure 3 , Figure 3 Step 104 shown can be achieved through Figure 5 Steps 1041 to 1043 shown are implemented.

[0121] In step 1041, the second scheduling model is used to predict, based on the sub-data query task, a first matching degree between the sub-data query task and each of the data query services, and a second probability for indicating whether the sub-data query task can be executed.

[0122] In some embodiments, for predicting the first matching degree, the first matching degree refers to the degree of fit between a sub-data query task and a certain data query service. A higher matching degree indicates that the service is more suitable for executing the sub-task. Prediction process: Analyze sub-task characteristics: Extract characteristics of the sub-data query task, such as query complexity, data source type, expected execution time, etc. Evaluate service characteristics: Evaluate the characteristics of each data query service, such as current load, performance, availability, etc. Calculate matching degree: Calculate the matching degree between the sub-task and each service based on the sub-task characteristics and service characteristics. The matching degree calculation can be based on various factors, such as: Current service load: Services with lower load have higher matching degrees. Service performance: Services with higher performance have higher matching degrees. Service availability: Services with higher availability have higher matching degrees. Data source distribution: Services closer to the data source have higher matching degrees. Output: The matching degree between each sub-data query task and each data query service.

[0123] In some embodiments, the second probability refers to the probability that a sub-data query task can be successfully executed on a certain data query service. The process involves: analyzing sub-task characteristics: extracting characteristics of the sub-data query task, such as query complexity, data source type, and historical execution success rate. Evaluating service characteristics: evaluating the characteristics of each data query service, such as current load, performance, and availability. Calculating execution probability: predicting the probability of successful execution of the sub-task on each service based on the sub-task characteristics and service characteristics. The calculation of execution probability can be based on various factors, such as: the current load of the service (services with lower load have a higher execution probability); the performance of the service (services with higher performance have a higher execution probability); the availability of the service (services with higher availability have a higher execution probability); and historical execution data (the historical execution success rate of similar tasks on this service). Output: the execution probability of each sub-data query task on each data query service.

[0124] As an example, feature extraction is performed on the sub-data query task to obtain sub-query task features. For example, for the sub-task "extract user order information from the order table within the past year", the extracted features might include: query statement complexity: high; data source type: order table; query conditions: time range (past year); historical execution time: average 2 seconds; First prediction layer: based on the sub-query task features, predict the matching degree between the sub-data query task and each data query service. For example, for services A, B, and C: matching degree of service A: 0.9; matching degree of service B: 0.6; matching degree of service C: 0.3. Second prediction layer: based on the sub-query task features, predict the probability that the sub-data query task can be successfully executed on each data query service. For example, for services A, B, and C: execution probability of service A: 0.95; execution probability of service B: 0.75; execution probability of service C: 0.50.

[0125] In some embodiments, the second scheduling model described above includes a feature extraction layer, a first prediction layer, and a second prediction layer. Step 1041 described above can be implemented as follows: through the feature extraction layer, features are extracted from the sub-data query task to obtain sub-query task features; through the first prediction layer, based on the sub-query task features, a first matching degree between the sub-data query task and each of the data query services is predicted; through the second prediction layer, based on the sub-query task features, a second probability for indicating that the sub-data query task can be executed is predicted.

[0126] In some embodiments, the second scheduling model consists of three main layers: a feature extraction layer responsible for extracting key features from the sub-data query tasks; a first prediction layer that, based on the extracted features, predicts the matching degree between the sub-data query tasks and each data query service; and a second prediction layer that, based on the extracted features, predicts the probability that the sub-data query tasks can be successfully executed on each data query service.

[0127] In some embodiments, key features are extracted from the sub-data query task, which will be used in subsequent prediction processes. Input: Sub-data query task. Output: Sub-query task features. Query statement analysis: Extracting the structure, complexity, data source types involved, query conditions, etc., of the query statement. Data source information: Extracting information such as the location and data volume of the data sources involved in the query. Historical execution data: Extracting historical execution time, resource consumption, etc., of similar query tasks. Other features: Extracting other factors that may affect task execution, such as the length of the query statement and the number of tables involved.

[0128] In some embodiments, for extracted subquery task features, the matching degree between the sub-data query task and each data query service is predicted. Input: Subquery task features. Output: The first matching degree between the sub-data query task and each data query service. Matching degree calculation: Calculate the matching degree between each sub-task and each service based on the subquery task features and service characteristics (such as current load, performance, availability, etc.). Matching degree evaluation: A higher matching degree indicates that the service is more suitable for executing the sub-task. The matching degree calculation can be based on various factors, such as: Current service load: Services with lower load have higher matching degrees. Service performance: Services with higher performance have higher matching degrees. Service availability: Services with higher availability have higher matching degrees. Data source distribution: Services closer to the data source have higher matching degrees.

[0129] In some embodiments, based on the extracted subquery task features, the probability of a sub-data query task successfully executing on each data query service is predicted. Execution probability calculation: Based on the subquery task features and service characteristics (such as current load, performance, availability, etc.), the probability of each sub-task successfully executing on each service is predicted. Probability evaluation: A higher execution probability indicates a greater likelihood of successful execution of the sub-task on that service. Probability calculation can be based on various factors, such as: Current service load: Services with lower load have a higher execution probability. Service performance: Services with higher performance have a higher execution probability. Service availability: Services with higher availability have a higher execution probability. Historical execution data: The historical success rate of similar tasks on that service.

[0130] As an example, the feature extraction layer extracts features from the sub-data query task to obtain sub-query task features. For example, for the sub-task of extracting user order information from the order table over the past year, the extracted features might include: query complexity: high; data source type: order table; query conditions: time range (past year); historical execution time: average 2 seconds. The first prediction layer predicts the matching degree between the sub-data query task and each data query service based on the sub-query task features. For example, for services A, B, and C: matching degree for service A: 0.9; matching degree for service B: 0.6; matching degree for service C: 0.3. The second prediction layer predicts the probability that the sub-data query task can be successfully executed on each data query service based on the sub-query task features. For example, for services A, B, and C: execution probability for service A: 0.95; execution probability for service B: 0.75; execution probability for service C: 0.50.

[0131] Thus, the feature extraction layer extracts features from the sub-data query task, obtaining the sub-query task features. This process quickly identifies key attributes of the task, such as the complexity of the query statement and the types of data sources involved, providing foundational data for subsequent predictions. Next, the first prediction layer, based on these features, predicts the first matching degree between the sub-data query task and each data query service. This matching degree calculation comprehensively considers the task features and the current state of the services, such as load and performance, thereby accurately assessing which services are most suitable for executing specific sub-tasks. Simultaneously, the second prediction layer, based on the same features, predicts the second probability of the sub-data query task successfully executing on each service. This probability prediction further enhances the system's decision-making capabilities, enabling the system not only to select the most suitable service but also to assess the likelihood of the task successfully executing on that service. Through this dual prediction mechanism, the system can make more informed decisions during resource allocation and task execution, improving the success rate and efficiency of task execution while optimizing resource utilization and avoiding resource waste.

[0132] In step 1042, the second probability is compared with the probability threshold to obtain a second comparison result.

[0133] In some embodiments, the second comparison result is used to indicate whether the second probability is greater than the probability threshold. If the second probability is not greater than the probability threshold, a prompt message is output to indicate that the data query failed.

[0134] In step 1043, if the second comparison result indicates that the second probability is greater than the probability threshold, then based on the first matching degree, the target data query service corresponding to the sub-data query task is determined from the plurality of data query services.

[0135] In some embodiments, the second probability is predicted by the second prediction layer and indicates the probability that a sub-data query task can be successfully executed on a certain data query service. The probability threshold is a preset threshold used to determine whether the likelihood of the task's successful execution is high enough. The second comparison result is a Boolean value obtained by comparing the second probability with the probability threshold. If the second probability is greater than the probability threshold, the comparison result is "yes"; otherwise, it is "no".

[0136] In some embodiments, the second probability is greater than the probability threshold: this means the predictive model believes the sub-data query task has a high probability of successful execution on a certain data query service. In this case, the system can continue to execute the query task and select the most suitable service based on the first matching degree. The second probability is not greater than the probability threshold: this means the predictive model believes the sub-data query task has a low probability of success on a certain data query service. This is because the query task is too complex, involves too much data, has too high a service load, or has other potential problems.

[0137] In some embodiments, if the second probability is not greater than a probability threshold, the system outputs a prompt message to inform the user that the data query task may fail. The prompt message can be text, a warning sign, or other forms of user interface feedback. The purpose of the prompt message is to inform the user in advance that the query task may not be successfully executed, thereby avoiding long waiting times or wasting system resources. Users can adjust query conditions, optimize query statements, or choose other query methods based on the prompt message.

[0138] In some embodiments, a first matching degree is obtained through a first prediction layer and indicates the degree of fit between the sub-data query task and each data query service. Target service selection: If a second probability is greater than a probability threshold, the system selects the most suitable service from multiple data query services based on the first matching degree. Selection criteria typically include: Highest matching degree: The service with the highest matching degree is selected because it best meets the task's requirements. Load balancing: Among multiple services with high matching degrees, the service with the lowest current load is selected to optimize resource allocation. Optimal performance: The service with the highest performance is selected to improve query efficiency.

[0139] As an example, suppose a user submits a complex query task in a distributed database system. The system breaks it down into multiple subtasks and predicts the execution probability and matching degree of each subtask on different services using a second scheduling model. For a certain subtask, the system predicts its second probability on service A to be 0.9 (90%), on service B to be 0.6 (60%), and on service C to be 0.3 (30%). Assume the probability threshold is 0.7 (70%). Comparison results: The second probability of service A (0.9) is greater than the probability threshold (0.7). The second probability of service B (0.6) is less than the probability threshold (0.7). The second probability of service C (0.3) is less than the probability threshold (0.7). For services B and C, since the second probability is less than the probability threshold, the system outputs a prompt: the query task may fail on this service; please select another service or optimize the query conditions. For service A, since the second probability is greater than the probability threshold, the system further evaluates the first matching degree: the matching degree of service A is 0.8 (high matching degree). The matching degree of service B is 0.6 (medium matching degree). Service C has a matching degree of 0.4 (low matching degree). Select service A with the highest matching degree as the target data query service and execute this subtask.

[0140] Thus, feature extraction is performed on each sub-data query task to obtain sub-query task features, which reflect the complexity and resource requirements of the task. Next, the first prediction layer predicts the first matching degree between the sub-task and each data query service based on these features. This process comprehensively considers factors such as the current load, performance, and availability of the service, ensuring the rationality of task allocation. Simultaneously, the second prediction layer predicts the second probability of successful execution of the sub-task on each service based on the same features. This probability prediction provides a reliability assessment for task execution. By comparing the second probability with a preset probability threshold, the system can filter out tasks with low success rates, avoiding wasting resources on these tasks. When the second probability is greater than the probability threshold, the system further selects the most suitable service from multiple data query services to execute the sub-task based on the first matching degree. This selection process not only considers the adaptability between the task and the service but also takes into account the overall resource allocation and load balancing of the system.

[0141] In step 105, the target data interface service corresponding to the sub-data query task is determined from multiple data interface services corresponding to the target data query service based on the third scheduling model through the target data query service.

[0142] In some embodiments, the target data query service is selected by a second scheduling model as the most suitable data query service for executing a particular sub-data query task. The target data query service provides the computational resources and data access capabilities required to execute the sub-task. The third scheduling model is an algorithm or set of rules used to manage and optimize the further allocation of sub-data query tasks within the target data query service. It typically considers factors such as task characteristics, the performance of data interface services, and load. Resource optimization: Improves resource utilization by rationally allocating sub-tasks to different data interface services. Load balancing: Ensures even load distribution within the target data query service, avoiding overload of certain data interface services. Performance optimization: Improves query efficiency by selecting the most suitable data interface service for executing each sub-task.

[0143] As an example, the subtask characteristics are: complex query statements involving a large amount of data, and a long expected execution time. Interface 1: currently has low load and high performance, suitable for complex queries. Interface 2: currently has medium load and medium performance, suitable for medium-complexity queries. Interface 3: currently has high load and low performance, suitable for simple queries. Selection result: Based on the subtask characteristics and service features, Interface 1 is selected as the target data interface service because it currently has low load and high performance, making it suitable for complex queries.

[0144] In some embodiments, step 105 above can be implemented as follows: using the third scheduling model, based on the sub-data query task, predicting a second matching degree between the sub-data query task and each of the data interface services, and a third probability indicating that the sub-data query task can be executed; comparing the third probability with a probability threshold to obtain a third comparison result; if the third comparison result indicates that the third probability is greater than the probability threshold, then using the target data query service, based on the second matching degree, determining the target data interface service corresponding to the sub-data query task from the plurality of data interface services.

[0145] In some embodiments, the third scheduling model includes a feature extraction layer, a first prediction layer, and a second prediction layer. The third scheduling model, based on the sub-data query task, predicts a second matching degree between the sub-data query task and each of the data interface services, and a third probability indicating that the sub-data query task can be executed. This can be achieved as follows: The feature extraction layer extracts features from the sub-data query task to obtain sub-query task features; the first prediction layer predicts the second matching degree between the sub-data query task and each of the data interface services based on the sub-query task features; and the second prediction layer predicts the second probability indicating that the sub-data query task can be executed based on the sub-query task features.

[0146] In some embodiments, the third scheduling model is an algorithm or set of rules used to manage and optimize the further allocation of sub-data query tasks across the target data query service. It typically considers factors such as task characteristics, the performance and load of the data interface services. Its functions include: Resource optimization: Improving resource utilization by rationally allocating sub-tasks to different data interface services. Load balancing: Ensuring a uniform load distribution across the target data query service, preventing overload of certain data interface services. Performance optimization: Selecting the most suitable data interface service for executing each sub-task, improving query efficiency.

[0147] In some embodiments, the second matching degree refers to the degree of compatibility between a sub-data query task and a certain data interface service. A higher matching degree indicates that the service is more suitable for executing the sub-task. The process involves: analyzing sub-task characteristics: extracting characteristics of the sub-data query task, such as query complexity, data source type, and expected execution time. Evaluating data interface service characteristics: evaluating the characteristics of each data interface service, such as current load, performance, and availability. Calculating the matching degree: calculating the matching degree between the sub-task and each data interface service based on the sub-task characteristics and service characteristics. The matching degree can be calculated based on various factors, such as: the current load of the service (services with lower load have higher matching degrees); the performance of the service (services with higher performance have higher matching degrees); the availability of the service (services with higher availability have higher matching degrees); and the distribution of the data source (services closer to the data source have higher matching degrees).

[0148] In some embodiments, the third probability refers to the probability that a sub-data query task can be successfully executed on a certain data interface service. The process involves: analyzing sub-task characteristics: extracting characteristics of the sub-data query task, such as query complexity, data source type, and historical execution success rate. Evaluating data interface service characteristics: evaluating the characteristics of each data interface service, such as current load, performance, and availability. Calculating execution probability: predicting the probability of successful execution of the sub-task on each data interface service based on the sub-task characteristics and service characteristics. The calculation of execution probability can be based on various factors, such as: the current load of the service (services with lower load have a higher execution probability); the performance of the service (services with higher performance have a higher execution probability); the availability of the service (services with higher availability have a higher execution probability); and historical execution data (the historical execution success rate of similar tasks on this service).

[0149] In some embodiments, the probability threshold is a preset threshold used to determine whether the likelihood of task success is high enough. The third comparison result is a Boolean value obtained by comparing the third probability with the probability threshold. If the third probability is greater than the probability threshold, the comparison result is yes; otherwise, it is no.

[0150] In some embodiments, a third probability is compared with a probability threshold: if the third probability is greater than the probability threshold, it indicates that the task has a high success rate on that data interface service. Target data interface service selection: Based on the second matching degree, the most suitable service is selected from multiple data interface services. Selection criteria typically include: Highest matching degree: The service with the highest matching degree is selected because it best meets the task's needs. Load balancing: Among multiple services with high matching degrees, the service with the lowest current load is selected to optimize resource allocation. Optimal performance: The service with the highest performance is selected to improve query efficiency.

[0151] As an example, suppose in a distributed database system, the target data query service (service A) has multiple data interface services (interface 1, interface 2, interface 3), each with different performance and load. The system needs to select the most suitable data interface service for a certain sub-data query task. Predict the second matching degree. Sub-task characteristics: complex query statement, involving a large amount of data, and expected long execution time. Matching degree of interface 1: 0.9 (high matching degree). Matching degree of interface 2: 0.6 (medium matching degree). Matching degree of interface 3: 0.3 (low matching degree). Predict the third probability: Execution probability of interface 1: 0.95 (high probability), execution probability of interface 2: 0.75 (medium probability), execution probability of interface 3: 0.50 (low probability). Comparison results: The third probability of interface 1 (0.95) is greater than the probability threshold (0.7). The third probability of interface 2 (0.75) is greater than the probability threshold (0.7). The third probability of interface 3 (0.50) is less than the probability threshold (0.7). Selection result: Based on the second matching degree, interface 1 is selected as the target data interface service because it not only has the highest matching degree, but also has an execution probability higher than the probability threshold.

[0152] Thus, based on the characteristics of sub-data query tasks, the system predicts a second degree of matching between each task and various data interface services. This comprehensively considers factors such as task complexity, data source type, and the current load and performance of the services, enabling accurate assessment of which services are best suited for executing specific sub-tasks. Simultaneously, the model predicts a third probability of successful execution of the sub-task on each service, providing a reliability assessment for task execution. By comparing the third probability with a preset probability threshold, the system can filter out tasks with low success rates, avoiding wasting resources on these tasks. When the third probability exceeds the probability threshold, the system further selects the most suitable service from multiple data interface services based on the second degree of matching to execute the sub-task, considering not only the compatibility between tasks and services but also the overall resource allocation and load balancing of the system.

[0153] In step 106, the target data interface corresponding to the sub-data query task is determined from multiple data interfaces corresponding to the target data interface service based on the fourth scheduling model through the target data interface service.

[0154] In some embodiments, the target data interface service is selected by a third scheduling model as the most suitable data interface service for executing a particular sub-data query task. The target data interface service provides the specific data access interfaces required to execute the sub-task, connecting to the actual data store or data source. The fourth scheduling model is an algorithm or set of rules used to manage and optimize the further allocation of sub-data query tasks among the target data interface services. It typically considers factors such as task characteristics, the performance of the specific data interface, and its load.

[0155] In some embodiments, the subtask characteristics are analyzed: Features of the sub-data query task are extracted, such as query complexity, data source type, and expected execution time. Specific data interface characteristics are evaluated: The characteristics of each specific data interface in the target data interface service are evaluated, such as current load, performance, and availability. Target data interface is selected: Based on the above evaluation, the most suitable specific data interface for executing the subtask is selected. Selection criteria may include: Current interface load: Interfaces with lower load have a higher match rate. Interface performance: Interfaces with higher performance have a higher match rate. Interface availability: Interfaces with higher availability have a higher match rate. Data source distribution: Interfaces closer to the data source have a higher match rate. A target data interface is assigned to each sub-data query task.

[0156] In some embodiments, step 106 above can be implemented as follows: using the fourth scheduling model, based on the sub-data query task, predicting the third matching degree between the sub-data query task and each of the data interfaces, and a fourth probability indicating that the sub-data query task can be executed; comparing the fourth probability with a probability threshold to obtain a fourth comparison result; if the fourth comparison result indicates that the fourth probability is greater than the probability threshold, then using the target data interface service, based on the third matching degree, determining the target data interface corresponding to the sub-data query task from the plurality of data interfaces.

[0157] In some embodiments, the fourth scheduling model includes a feature extraction layer, a first prediction layer, and a second prediction layer. The fourth scheduling model, based on the sub-data query task, predicts a third matching degree between the sub-data query task and each of the data interfaces, and a fourth probability indicating that the sub-data query task can be executed. This can be achieved as follows: The feature extraction layer extracts features from the sub-data query task to obtain sub-query task features; the first prediction layer predicts the third matching degree between the sub-data query task and each of the data interfaces based on the sub-query task features; and the second prediction layer predicts the fourth probability indicating that the sub-data query task can be executed based on the sub-query task features.

[0158] In some embodiments, the fourth scheduling model is an algorithm or set of rules used to manage and optimize the further allocation of sub-data query tasks across the target data interface service. It typically considers factors such as task characteristics, the performance of specific data interfaces, and their load. Its functions include: Resource optimization: Improving resource utilization by rationally allocating sub-tasks to different specific data interfaces. Load balancing: Ensuring a uniform load distribution across the target data interface service, preventing overload of certain data interfaces. Performance optimization: Improving query efficiency by selecting the most suitable specific data interface for executing each sub-task.

[0159] In some embodiments, the third matching degree refers to the degree of fit between a sub-data query task and a specific data interface. A higher matching degree indicates that the interface is more suitable for executing the sub-task. Features of the sub-data query task are extracted, such as query complexity, data source type, and expected execution time. The characteristics of each specific data interface in the target data interface service are evaluated, such as current load, performance, and availability. Based on the sub-task characteristics and interface characteristics, the matching degree between the sub-task and each specific data interface is calculated. The matching degree calculation can be based on various factors, such as: current interface load (interfaces with lower load have higher matching degrees); interface performance (interfaces with higher performance have higher matching degrees); interface availability (interfaces with higher availability have higher matching degrees); and data source distribution (interfaces closer to the data source have higher matching degrees).

[0160] In some embodiments, the fourth probability refers to the probability that a sub-data query task can be successfully executed on a specific data interface. The process involves: analyzing sub-task characteristics: extracting features of the sub-data query task, such as query complexity, data source type, and historical execution success rate. Evaluating specific data interface characteristics: assessing the characteristics of each specific data interface, such as current load, performance, and availability. Calculating execution probability: predicting the probability of successful execution of the sub-task on each specific data interface based on the sub-task characteristics and interface characteristics. The calculation of execution probability can be based on various factors, such as: current interface load (interfaces with lower load have a higher execution probability); interface performance (interfaces with higher performance have a higher execution probability); interface availability (interfaces with higher availability have a higher execution probability); and historical execution data (the historical execution success rate of similar tasks on this interface).

[0161] In some embodiments, the probability threshold is a preset threshold used to determine whether the likelihood of task success is high enough. The fourth comparison result is a Boolean value obtained by comparing the fourth probability with the probability threshold. If the fourth probability is greater than the probability threshold, the comparison result is yes; otherwise, it is no.

[0162] In some embodiments, if the fourth probability is greater than a probability threshold, it indicates that the task has a high success rate on that data interface. Based on the third matching degree, the most suitable data interface is selected from multiple specific data interfaces. Selection criteria typically include: Highest matching degree: Select the interface with the highest matching degree, as it best meets the task's requirements. Load balancing: Among multiple interfaces with high matching degrees, select the interface with the lowest current load to optimize resource allocation. Optimal performance: Select the interface with the highest performance to improve query efficiency. A target data interface is assigned to each sub-data query task.

[0163] As an example, suppose in a distributed database system, the target data interface service (service A) has multiple specific data interfaces (interface 1, interface 2, interface 3), each with different performance and load. The system needs to select the most suitable specific data interface for a certain sub-data query task. Predicting the third matching degree sub-task characteristics: complex query statement, involving a large amount of data, and expected long execution time. Interface 1 matching degree: 0.9 (high matching degree). Interface 2 matching degree: 0.6 (medium matching degree). Interface 3 matching degree: 0.3 (low matching degree); Predicting the fourth probability. Interface 1 execution probability: 0.95 (high probability). Interface 2 execution probability: 0.75 (medium probability). Interface 3 execution probability: 0.50 (low probability); The fourth probability of Interface 1 (0.95) is greater than the probability threshold (0.7). The fourth probability of Interface 2 (0.75) is greater than the probability threshold (0.7). The fourth probability of Interface 3 (0.50) is less than the probability threshold (0.7). Based on the third matching degree, interface 1 is selected as the target data interface because it not only has the highest matching degree, but also has an execution probability higher than the probability threshold.

[0164] Thus, the fourth scheduling model, based on the characteristics of sub-data query tasks, predicts the third matching degree between each task and each data interface. This process comprehensively considers factors such as task complexity, data source type, and the current load and performance of the interface, thereby accurately assessing which interfaces are most suitable for executing specific sub-tasks. Simultaneously, the model also predicts the fourth probability of successful execution of the sub-task on each interface; this probability prediction provides a reliability assessment for task execution. By comparing the fourth probability with a preset probability threshold, the system can filter out tasks with low success rates, avoiding wasting resources on these tasks. When the fourth probability is greater than the probability threshold, the system further selects the most suitable data interface from multiple data interfaces based on the third matching degree to execute the sub-task. This selection process not only considers the compatibility between the task and the interface but also takes into account the overall resource allocation and load balancing of the system.

[0165] In step 107, the sub-data query task corresponding to each target data interface is executed through the target data interface corresponding to each sub-data query task to obtain the sub-data query result corresponding to each sub-data query task.

[0166] In some embodiments, the target data interface is selected by a fourth scheduling model as the most suitable specific data interface for executing a sub-data query task. The target data interface provides the specific data access path required to execute the sub-task, connecting to the actual data storage or data source. Task allocation: Each sub-data query task is assigned to its corresponding target data interface. Task execution: Each sub-data query task is executed through the target data interface. The execution process includes: Data access: Accessing the actual data storage or data source through the target data interface. Query execution: Executing the query operation according to the query statement of the sub-data query task. Result generation: Generating the query results for each sub-data query task.

[0167] As an example, suppose there are multiple sub-data query tasks in a distributed database system, each task being assigned to the most suitable target data interface through a fourth scheduling model. The system needs to execute query tasks through these target data interfaces and obtain query results. Task allocation: Subtask 1: assigned to target data interface 1. Subtask 2: assigned to target data interface 2. Subtask 3: assigned to target data interface 3.

[0168] Continuing the previous example, Subtask 1: Access the data source through target data interface 1. Execute a query statement, for example: SELECT * FROM table1 WHERE condition1. Generate query results, for example: [{"id": 1, "value": "data1"}, {"id": 2, "value": "data2"}]. Subtask 2: Access the data source through target data interface 2. Execute a query statement, for example: SELECT * FROM table2 WHERE condition2. Generate query results, for example: [{"id": 3, "value": "data3"}, {"id": 4, "value": "data4"}]. Subtask 3: Access the data source through target data interface 3. Execute a query statement, for example: SELECT * FROM table3 WHERE condition3. Generate query results, for example: [{"id": 5, "value": "data5"}, {"id": 6, "value": "data6"}].

[0169] In step 108, the sub-data query results corresponding to multiple sub-data query tasks are merged to obtain the data query result.

[0170] In some embodiments, sub-data query results refer to the query results generated after each sub-data query task is executed. These results are typically partial data or intermediate results that require further processing to generate the final data query result. Result fusion refers to merging multiple sub-data query results into a complete data query result. This process typically involves operations such as data merging, deduplication, sorting, and formatting. The goal is to generate a complete and consistent data query result, which is then provided to the user or caller.

[0171] In some embodiments, all sub-data query results are merged into a unified data structure. For example, multiple result lists are merged into a single list. If duplicate data items exist in the sub-data query results, deduplication is required. The merged data is sorted as needed. For example, it can be sorted by a specific field (such as id). The merged data is then formatted into the final query result. For example, the data can be converted to JSON or tabular format.

[0172] As an example, suppose in a distributed database system there are multiple sub-data query tasks, each executed through a target data interface and generating partial query results. The system needs to merge these results to generate the final data query result (specifically, the partial query results generated by the target data interface are passed up the system layer by layer (see...)). Figure 6 The system shown progresses from the data table layer to the query construction layer, from the query construction layer to the agent layer, from the agent layer to the A2A agent selection layer, and from the A2A agent selection layer to the main agent layer (A2A host layer). The A2A host layer aggregates the query results, and the final aggregated results are integrated through a large language model to provide semantic answers to user interaction questions. The results of subtask 1 are: [{"id": 1, "value": "data1"}, {"id": 2, "value": "data2"}]; the results of subtask 2 are: [{"id": 3, "value": "data3"}, {"id": 4, "value": "data4"}]; the results of subtask 3 are: [{"id": 5, "value": "data5"}, {"id": 6, "value": "data6"}]. All results are merged into a list, and duplicate data items are checked and removed (if any). The data is then sorted by the id field. The merged data is formatted into the final query result.

[0173] Thus, upon responding to a data query command, the complex data query task is broken down into multiple subtasks based on the first scheduling model. By analyzing the complexity and resource requirements of the tasks, the task scale is rationally allocated, ensuring that each subtask can execute independently, providing a foundation for parallel processing. Next, for each subtask, the second scheduling model selects the most suitable service from multiple data query services. This selection is based on factors such as service load, performance, and availability, ensuring efficient resource utilization. The third scheduling model further refines the selection process, determining the target data interface service for each subtask from multiple data interface services corresponding to the target data query service. The fourth scheduling model selects the most suitable interface from multiple specific data interfaces corresponding to the target data interface service to execute the subtask. This process ensures that each subtask can execute efficiently on the most suitable data interface. Through this layered and refined scheduling process, each subtask can execute in an optimized environment, generating sub-data query results. These results are then fused to obtain the complete data query result. This hierarchical scheduling mechanism not only optimizes resource allocation and improves the success rate of task execution but also significantly reduces query time through parallel processing, thereby significantly improving overall data query efficiency.

[0174] The following will describe an exemplary application of the embodiments of this application in a real data query application scenario.

[0175] Large Language Models (LLMs) are a class of generative AIs based on deep neural networks and self-supervised pre-training on corpora of trillions of words. They are capable of understanding and generating multi-language text, code, tables, and other multimodal content. Thanks to their large-scale parameters and context learning mechanisms, they exhibit emergent capabilities such as reasoning, dialogue, programming, and retrieval enhancement, and are becoming the core engine of general intelligent systems.

[0176] In high-cost, sensitive big data query services primarily serving the financial and government sectors, the sheer volume of hundreds of millions of data points and the availability of hundreds of thousands of API tools make it difficult to achieve cost-effective and efficient accurate data retrieval using traditional and manual methods. With the continuous improvement of LLM platform performance and the widespread adoption of the MCP (Model Context Protocol), architectures such as React and Planner-Execute have emerged, enabling mainstream LLMs to call MCP tools and perform functions such as code execution, speech conversion, and enhanced retrieval. This significantly expands their functional scope, forming intelligent agents.

[0177] NL2SQL, which translates natural language into database query commands, is also a crucial tool for the MCP (Multi-Channel Programming) required by LLM (Low-Level Modeling). NL2SQL tools based on large models can be embedded as MCP tools in database-oriented applications, commonly found in business question-answering agents with complex multi-table queries. This approach provides a feasible path for data querying techniques based on MCP and agents, but it still doesn't solve the core problem of balancing cost, efficiency, and accuracy in handling massive amounts of data.

[0178] Recently, with Google's release of the standard A2A (Agent to Agent) protocol, heterogeneous AI agents will be able to achieve efficient collaboration while ensuring security. For massive amounts of data, applying more complex hierarchical data retrieval designs will significantly reduce the time complexity of data queries, and the A2A protocol provides the technical foundation for the integration and collaboration of data query agents previously based on one-step MCP calls. On the other hand, in data query systems built on A2A-MCP systems, errors are not "immediately exposed" as in single-layer calls, but are amplified and accumulated layer by layer. At the same time, as the hierarchy deepens, the cost of queries increases further; if the same problem reaches redundant agents / tools, the bill increases exponentially. Therefore, the key to designing a robust A2A-MCP system will be to design a supporting reinforcement learning-based scheduling system.

[0179] This application proposes a hierarchical scheduling-based big data service for commercial queries based on the A2A-MCP framework. This application minimizes time complexity through more than ten hierarchical layers, and simultaneously sets up schedulers at key layers. During the Agent / Tool selection process at each layer, multiple candidate query paths are generated synchronously. Reinforcement learning updates are performed based on a relative reward signal that comprehensively considers accuracy, latency, and economic cost, thereby significantly reducing overall call costs while ensuring retrieval accuracy. This method enables cross-agent query processes in massive data environments to stably converge to the cost-benefit optimal path within a limited number of rounds, providing a feasible and scalable intelligent retrieval solution for massive data in comprehensive commercial query scenarios.

[0180] Big data leads to an explosion in computational complexity: suppose a complete query chain requires... Layers: Data → Table → DB → API → … → User. (Note the first...) The set of optional actions for a layer Quantity is If a brute-force search is used, the computational complexity is equivalent to the total path combination. (1) The embodiments of this application use Key steps in a hierarchical retrieval chain are considered as (2) Training a four-level scheduler Transformer encoding Make discrete decisions within the candidate subset. shortened to (3) Each level scheduler will assign corresponding instructions to the A2A, agent or MCP at that level, including routing, TOP-K and early interception probability. This controls the total number of query links, reducing computational complexity to a manageable level. Deep-seated errors accumulate. Traditional Top-K filtering strategies using simple thresholds and fixed pipeline designs introduce errors or uncertainties into each level of the multi-level link because the threshold and direction are simply specified. Since inaccurate information returned by a particular API can mislead subsequent decisions, these errors may gradually amplify as the link length increases. Without an effective control mechanism, the reliability of the final result is difficult to guarantee. Previous methods lacked this mechanism. In this application's embodiment, the Top-k threshold is adjusted in real-time based on the scheduler's network output, context, and budget; the stopping threshold... Guaranteed by Taylor's upper bound Meanwhile, this application's embodiments introduce a feedback-based hierarchical scheduling mechanism. A scheduler built on three levels performs policy control from top to bottom and provides feedback on accuracy, cost, latency, and other information from bottom to top, thereby controlling the cumulative error propagating to deeper layers. Limiting only the Top-K at the bottom layer cannot guarantee the number of global API calls. Converging to the budget In this embodiment, the optimization algorithm under dual budget constraints ensures early termination when the local accuracy increment decreases with further computation. Simultaneously, the optimization is performed under a constrained model, the mathematical form of which is... At the same time, by using Update Lagrange multipliers This ensures the second constraint. Always stuck at the budget line Nearby. Policy oscillation: Multi-level retrieval often only yields meaningful feedback (e.g., the accuracy of the final answer) in the final stage. The lack of direct reward signals in intermediate steps leads to extremely sparse rewards during reinforcement learning training, making it difficult for the agent to measure the contribution of each decision to the final result. If the classic PPO reinforcement learning strategy is used, training with highly sparse rewards is extremely unstable and prone to KL divergence. To ensure the learnability and stable convergence of the policy in extremely sparse reward scenarios, this application adopts a bottom-up freeze-thaw process: first, the lowest-level policy is trained and converged, then locked, and then unfrozen layer by layer, optimizing the upper layers to avoid inter-layer noise interference. Within each layer, GRPO is applied, generating an advantage signal through relative ranking within the group and updating it within the KL trust domain, achieving stable convergence under sparse reward conditions without a value network.

[0181] In some embodiments, see Figure 6 , Figure 6 This is a schematic diagram of the principle of the multi-agent collaborative data query method provided in the embodiments of this application. Figure 1 The overall retrieval link for users to query the underlying data is expanded into a complex "11+4" structure consisting of an eleven-level directed acyclic tree diagram and a four-level scheduler.

[0182] In some embodiments, see Figure 6 The application design presents an "11+4" retrieval chain structure consisting of an eleven-level hierarchical retrieval chain and a four-level scheduler, and considers this an important part of the patent protection scope. This structure subdivides a complete information retrieval process into eleven operational units, with the parameters of the four key routing levels controlled by the corresponding four-level schedulers. The functions of each level and each scheduler are as follows: Level 1: User Input Layer (User), where the user carries query information. Level 2: Application Interaction Layer (Application), which should include a graphical interface to interact with the user, obtain query information, and pass it to subsequent layers; subsequently, the retrieved data is fed back to the user. Level 3: Main Agent Layer (A2A Host), where the overall scheduler (Scheduler 1) (i.e., the first scheduling model described above) and the Agent Host respectively parse the user's query data. Scheduler 1 obtains the route, Top-K, and cutoff probability through a Transformer using the input query information. The system processes and presents this information to the Agent Host, which then parses, infers, breaks down, and processes the user's query. The fourth level is the A2A selection layer (A2A Client). The A2A Host divides the overall query task into several subtasks and, according to the instructions given by Scheduler 1, selects the appropriate sub-A2A Server to handle different subtasks or stop the task, thus achieving A2A collaborative work. The fifth level is the agent selection layer (A2A Server). For each A2A Client connected to an A2A Server, there is its own intrinsic secondary scheduler (Scheduler 2) (i.e., the second scheduling model described above), which determines the scale of Agent resources to use for each subtask. Simultaneously, the agents on the A2A Server side parse, infer, break down, and process the task, and select and activate the corresponding Agent according to the scheduler's instructions. Level 6: Agent Layer. Each Agent connected to the A2A Server may have its own built-in Level 3 scheduler (i.e., the third scheduling model described above). Of course, for Agents without a scheduler or not created within the system, static scheduling parameters can be estimated based on their Agent description and call history information. The Agent parses, infers, breaks down, and processes tasks, and selects and activates the corresponding type and number of MCP Clients according to the scheduler's instructions. Level 7: Query Construction Layer (MCPServer). Activated MCP Clients connect to the corresponding MCP Servers. These MCP Servers may have built-in Level 4 schedulers (i.e., the fourth scheduling model described above). If not, static scheduling parameters are considered. The scheduler determines the scale of API resources to use for each specific subtask, and the MCP Server activates the corresponding API to complete each subtask. Level 8: Tool Invocation Layer (API). This layer executes specific API request calls, sending the constructed query tasks to the target database interface, which may involve instruction conversions such as NL2SQL. This layer introduces asynchronous call mechanisms and fault tolerance mechanisms to improve retrieval efficiency and stability. Level 9: Database Layer (DB), accepts query commands and completes the query. Level 10: Table Layer (Table), stores data in table format. Level 11: Data Layer (Data), stores specific fields and data entries, which may be natural language, numbers, or other multimodal data. The above eleven-level structure clearly defines the responsibilities of each stage in the retrieval chain, ensuring high efficiency and reliability through layer-by-layer progression and feedback.

[0183] In some embodiments, see Figure 7 , Figure 7 This is a schematic diagram of the principle of the multi-agent collaborative data query method provided in the embodiments of this application. Figure 2 , Figure 7 The scheduler described above, as shown, is... Figure 6 The structures of the first, second, third, and fourth scheduling models are shown below. Let a scheduler be defined in the first... The observed state in the hierarchical MDP is Its interior consists of a branch Encoding addition, a three-headed policy network, together constitute as follows Figure 7 The structure is shown below. The following components are the scheduler's outputs and can regulate the behavior of this layer: Route header. In the candidate subtask set The above provides a discrete probability distribution for selecting the next-hop A2A / Agent / API and choosing the action. Activator-MDP Top-k head Integerized budget allocation is used to limit the number of branches that can be activated simultaneously at this layer. Termination Head Bernoulli probability controls whether the search chain is prematurely terminated at this level. If it occurs twice consecutively, it indicates an advantage. Then The chain is terminated early if the probability ends.

[0184] In some embodiments, the immediate reward for training the scheduler comprises three parts. , in This represents an improvement in accuracy and range. ; This represents the number of new branches triggered; This represents the cost of adding a new API call. The optimization issue of adding an early stopping mechanism is... ,in Update Lagrange multipliers This ensures the second constraint. Always stuck at the budget line nearby.

[0185] It is understood that in the embodiments of this application, data related to data query tasks and the like are required to obtain user permission or consent when the embodiments of this application are applied to specific products or technologies, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0186] The following description continues to illustrate the exemplary structure of the multi-agent collaborative data query device 455 provided in this application embodiment as a software module. In some embodiments, such as... Figure 2As shown, the software module in the multi-agent collaborative data query device 455 stored in the memory 450 may include: a splitting module, which is used to construct a data query task corresponding to the received data query instruction in response to the data query instruction, and split the data query task based on the first scheduling model to obtain multiple sub-data query tasks of the data query task;

[0187] The scheduling module is configured to, for each sub-data query task, determine the target data query service corresponding to the sub-data query task from multiple data query services based on a second scheduling model, and, through the target data query service, determine the target data interface service corresponding to the sub-data query task from multiple data interface services corresponding to the target data query service based on a third scheduling model; and, through the target data interface service, determine the target data interface corresponding to the sub-data query task from multiple data interfaces corresponding to the target data interface service based on a fourth scheduling model.

[0188] The query module is used to execute the sub-data query task corresponding to each target data interface through the target data interface corresponding to each sub-data query task, and obtain the sub-data query result corresponding to each sub-data query task.

[0189] The fusion module is used to merge the sub-data query results corresponding to multiple sub-data query tasks to obtain the data query result.

[0190] In some embodiments, the data query instruction carries at least one query statement. The aforementioned splitting module is further configured to, for each query statement, query an index entry containing the query statement from a preset statement-execution logic mapping relationship, and determine the execution logic in the index entry as the target execution logic corresponding to the query statement; and generate a data query task corresponding to the data query instruction based on the target execution logic corresponding to each query statement through a task construction model.

[0191] In some embodiments, the above-mentioned splitting module is further configured to predict, based on the data query instruction, a first number of the plurality of sub-data query tasks and a first probability indicating that the data query task can be executed, using the first scheduling model; compare the first probability with a probability threshold to obtain a first comparison result; if the first comparison result indicates that the first probability is greater than the probability threshold, then split the data query task into the plurality of sub-data query tasks based on the first number.

[0192] In some embodiments, the data query task includes target execution logic carried in the data query instruction for each query statement. The aforementioned splitting module is further configured to determine a second number of target execution logic in the data query task, and compare the second number with the first number to obtain a second comparison result; if the second comparison result indicates that the first number is less than or equal to the second number, then the data query task is split into the first number of sub-data query tasks; if the second comparison result indicates that the first number is greater than the second number, then the data query task is split into the second number of sub-data query tasks, wherein each sub-data query task includes at least one of the target execution logic.

[0193] In some embodiments, the first scheduling model includes a feature extraction layer, a first prediction layer, and a second prediction layer. The aforementioned splitting module is further configured to extract features from the data query instruction through the feature extraction layer to obtain query instruction features; predict a first number of the plurality of sub-data query tasks based on the query instruction features through the first prediction layer; and predict a first probability for indicating that the data query task can be executed based on the query instruction features through the second prediction layer.

[0194] In some embodiments, the scheduling module is further configured to, through the second scheduling model, predict a first matching degree between the sub-data query task and each of the data query services, and a second probability indicating that the sub-data query task can be executed; compare the second probability with a probability threshold to obtain a second comparison result; if the second comparison result indicates that the second probability is greater than the probability threshold, then, based on the first matching degree, determine the target data query service corresponding to the sub-data query task from the plurality of data query services.

[0195] In some embodiments, the second scheduling model includes a feature extraction layer, a first prediction layer, and a second prediction layer. The scheduling module is further configured to: extract features from the sub-data query task using the feature extraction layer to obtain sub-query task features; predict a first matching degree between the sub-data query task and each data query service using the first prediction layer based on the sub-query task features; and predict a second probability indicating that the sub-data query task can be executed using the second prediction layer based on the sub-query task features.

[0196] In some embodiments, the scheduling module is further configured to, through the third scheduling model, predict a second matching degree between the sub-data query task and each of the data interface services, and a third probability indicating that the sub-data query task can be executed; compare the third probability with a probability threshold to obtain a third comparison result; if the third comparison result indicates that the third probability is greater than the probability threshold, then, through the target data query service, based on the second matching degree, determine the target data interface service corresponding to the sub-data query task from the plurality of data interface services.

[0197] In some embodiments, the scheduling module is further configured to, through the fourth scheduling model, predict a third matching degree between the sub-data query task and each of the data interfaces, and a fourth probability indicating that the sub-data query task can be executed; compare the fourth probability with a probability threshold to obtain a fourth comparison result; if the fourth comparison result indicates that the fourth probability is greater than the probability threshold, then, through the target data interface service, determine the target data interface corresponding to the sub-data query task from the plurality of data interfaces based on the third matching degree.

[0198] This application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the multi-agent collaborative data query method described in this application embodiment.

[0199] This application provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are executed by a processor, they cause the processor to execute the multi-agent collaborative data query method provided in this application. For example, ... Figure 3 The data query method for multi-agent collaboration is shown.

[0200] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of electronic devices including one or any combination of the above-mentioned memories.

[0201] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0202] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0203] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0204] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A multi-agent collaborative data query method, characterized in that, The method includes: In response to a received data query instruction, a data query task corresponding to the data query instruction is constructed, and the data query task is split into multiple sub-data query tasks. For each of the sub-data query tasks, based on the first scheduling model, the target selection service for the sub-data query task is determined from the selection services of multiple intelligent agents; For each sub-data query task, based on the second scheduling model, a target data query service corresponding to the sub-data query task is determined from multiple data query services corresponding to the target selection service of the sub-data query task. Then, based on the target data query service, a target data interface service corresponding to the sub-data query task is determined from multiple data interface services corresponding to the target data query service, using the third scheduling model. Finally, based on the target data interface service, a target data interface corresponding to the sub-data query task is determined from multiple data interfaces corresponding to the target data interface service, using the fourth scheduling model. By executing the target data interface corresponding to each of the sub-data query tasks, the sub-data query task corresponding to each target data interface is obtained, and the sub-data query result corresponding to each sub-data query task is obtained. The sub-data query results corresponding to multiple sub-data query tasks are merged to obtain the data query result. The structures of the first scheduling model, the second scheduling model, the third scheduling model, and the fourth scheduling model include backbone network coding and a three-head policy network. The outputs of the first scheduling model, the second scheduling model, the third scheduling model, and the fourth scheduling model include a routing header, an activator sub-MDP, and a Top-k header. and termination head The routing header is in the candidate subtask set. The above provides a discrete probability distribution for selecting the next hop action. The Top-k head Integerized budget allocation, the number of branches to activate. The termination header Bernoulli probability controls whether the search chain terminates prematurely; if two consecutive steps are advantageous... Then The chain terminates prematurely due to probability.

2. The method according to claim 1, characterized in that, The data query instruction carries at least one query statement, and the step of constructing a data query task corresponding to the received data query instruction in response to the data query instruction includes: For each query statement, the index entries containing the query statement are retrieved from the preset statement-execution logic mapping relationship, and the execution logic in the index entries is determined as the target execution logic corresponding to the query statement; By constructing a task model, a data query task corresponding to the data query instruction is generated based on the target execution logic corresponding to each query statement.

3. The method according to claim 1, characterized in that, The process of splitting the data query task into multiple sub-data query tasks includes: Based on the data query instruction, a first number of the plurality of sub-data query tasks is predicted, and a first probability is used to indicate that the data query task can be executed; The first probability is compared with the probability threshold to obtain a first comparison result. If the first comparison result indicates that the first probability is greater than the probability threshold, then the data query task is divided into the multiple sub-data query tasks based on the first quantity.

4. The method according to claim 3, characterized in that, The data query task includes the data query instruction carrying the target execution logic corresponding to each query statement. The step of dividing the data query task into multiple sub-data query tasks based on the first quantity includes: Determine a second number of the target execution logic in the data query task, and compare the second number with the first number to obtain a second comparison result; If the second comparison result indicates that the first quantity is less than or equal to the second quantity, then the data query task is split into the first number of sub-data query tasks; If the second comparison result indicates that the first quantity is greater than the second quantity, then the data query task is split into the second number of sub-data query tasks, each sub-data query task including at least one of the target execution logic.

5. The method according to claim 3, characterized in that, The first scheduling model includes a feature extraction layer, a first prediction layer, and a second prediction layer. The step of predicting a first number of the plurality of sub-data query tasks based on the data query instruction using the first scheduling model, and a first probability indicating whether the data query task can be executed, includes: The feature extraction layer is used to extract features from the data query command to obtain query command features. Based on the query instruction characteristics, the first number of the multiple sub-data query tasks is predicted by the first prediction layer. The second prediction layer predicts a first probability that indicates the data query task can be executed based on the query instruction characteristics.

6. The method according to claim 1, characterized in that, The step of determining the target data query service corresponding to the sub-data query task from multiple data query services corresponding to the target selection service of the sub-data query task based on the second scheduling model includes: Using the second scheduling model, based on the sub-data query task, a first matching degree between the sub-data query task and each of the data query services is predicted, and a second probability is used to indicate whether the sub-data query task can be executed; The second probability is compared with a probability threshold to obtain a second comparison result. If the second comparison result indicates that the second probability is greater than the probability threshold, then based on the first matching degree, the target data query service corresponding to the sub-data query task is determined from the plurality of data query services.

7. The method according to claim 6, characterized in that, The second scheduling model includes a feature extraction layer, a first prediction layer, and a second prediction layer. The step of using the second scheduling model to predict, based on the sub-data query task, a first matching degree between the sub-data query task and each of the data query services, and a second probability indicating whether the sub-data query task can be executed, includes: The feature extraction layer is used to extract features from the sub-data query task to obtain the sub-query task features. Through the first prediction layer, based on the characteristics of the sub-query task, the first matching degree between the sub-data query task and each of the data query services is predicted; The second prediction layer predicts a second probability, based on the characteristics of the sub-query task, to indicate whether the sub-data query task can be executed.

8. The method according to claim 1, characterized in that, The step of determining the target data interface service corresponding to the sub-data query task from multiple data interface services corresponding to the target data query service based on the third scheduling model, through the target data query service, includes: Based on the sub-data query task, the third scheduling model predicts the second matching degree between the sub-data query task and each data interface service, and the third probability indicating whether the sub-data query task can be executed. The third probability is compared with the probability threshold to obtain a third comparison result. If the third comparison result indicates that the third probability is greater than the probability threshold, then the target data interface service corresponding to the sub-data query task is determined from the plurality of data interface services based on the second matching degree through the target data query service.

9. The method according to claim 1, characterized in that, The step of determining the target data interface corresponding to the sub-data query task from multiple data interfaces corresponding to the target data interface service based on the fourth scheduling model, through the target data interface service, includes: Based on the sub-data query task, the fourth scheduling model predicts the third matching degree between the sub-data query task and each data interface, as well as the fourth probability indicating that the sub-data query task can be executed. The fourth probability is compared with the probability threshold to obtain a fourth comparison result. If the fourth comparison result indicates that the fourth probability is greater than the probability threshold, then the target data interface corresponding to the sub-data query task is determined from the plurality of data interfaces based on the third matching degree through the target data interface service.

10. A multi-agent collaborative data query device, characterized in that, The device includes: The splitting module is used to respond to the received data query instruction, construct the data query task corresponding to the data query instruction, and split the data query task to obtain multiple sub-data query tasks of the data query task; for each sub-data query task, based on the first scheduling model, the target selection service of the sub-data query task is determined from multiple intelligent agent selection services; The scheduling module is configured to, for each sub-data query task, determine the target data query service corresponding to the sub-data query task from multiple data query services corresponding to the target selection service of the sub-data query task based on a second scheduling model; and, through the target data query service, determine the target data interface service corresponding to the sub-data query task from multiple data interface services corresponding to the target data query service based on a third scheduling model; and, through the target data interface service, determine the target data interface corresponding to the sub-data query task from multiple data interfaces corresponding to the target data interface service based on a fourth scheduling model. The query module is used to execute the sub-data query task corresponding to each target data interface through the target data interface corresponding to each sub-data query task, and obtain the sub-data query result corresponding to each sub-data query task. The fusion module is used to fuse the sub-data query results corresponding to multiple sub-data query tasks to obtain a data query result. The structures of the first scheduling model, the second scheduling model, the third scheduling model, and the fourth scheduling model include backbone network coding and a three-head policy network. The outputs of the first scheduling model, the second scheduling model, the third scheduling model, and the fourth scheduling model include a routing header, an activation sub-MDP, and a Top-k header. and termination head The routing header is in the candidate subtask set. The above provides a discrete probability distribution for selecting the next hop action. The Top-k head Integerized budget allocation, the number of branches to activate. The termination header Bernoulli probability controls whether the search chain terminates prematurely; if two consecutive steps are advantageous... Then The chain terminates prematurely due to probability.

Images