Data query method and apparatus

Abstract

An embodiment of the present application provides a data query method and device, comprising: in response to a query request input by a user, determining query intention information based on the query request; according to the query intention information, screening a target tool subset from a preset tool set, and determining a knowledge loading decision corresponding to the target tool subset; based on the target tool subset and the knowledge loading decision, calling a large language model to perform query processing to obtain a query execution result; performing rule verification processing on the query execution result, and outputting query response information after the verification passes. In this way, by screening the target tool subset based on the query intention information and determining the knowledge loading decision, the context Token transmission overhead and the server computing load can be reduced, and by means of the rule verification mechanism, repeated interaction caused by inaccurate results can be reduced, thereby improving the processing efficiency and accuracy of data query, and helping to alleviate the resource occupation of the server.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to data query methods and apparatus. Background Technology

[0002] In recent years, Text-to-SQL technology based on large language models has been widely used in natural language to database query conversion scenarios. A typical approach involves using a large language model to understand the user's natural language input and generate an SQL statement, which is then submitted to the database for execution to return the query results. To compensate for the lack of domain knowledge in large language models, some solutions pre-inject metadata information such as database table structures and field comments into the model context in text form, or introduce retrieval-enhanced generation techniques to retrieve relevant fragments from the knowledge base to assist in SQL generation, thereby lowering the data query threshold for non-technical personnel.

[0003] However, related technologies typically load all knowledge documents and context information into the model, which increases the context size of a single request, thereby increasing token transmission overhead and server computing load. In addition, due to the lack of a lightweight query result verification mechanism, inaccurate output content can easily trigger multiple repeated interactions between the terminal and the server, further consuming network and processing resources and affecting query response efficiency. Summary of the Invention

[0004] This application provides a data query method, apparatus, electronic device, and computer-readable storage medium to at least partially solve the aforementioned problems existing in the related art.

[0005] According to one aspect of this application, a data query method is provided, comprising: responding to a query request input by a user, determining query intent information based on the query request; filtering a subset of target tools from a preset toolset based on the query intent information, and determining a knowledge loading decision corresponding to the subset of target tools; calling a large language model to perform query processing based on the subset of target tools and the knowledge loading decision, and obtaining query execution results; performing rule validation processing on the query execution results, and outputting query response information after the validation passes.

[0006] According to one aspect of this application, a data query apparatus is provided, comprising: a response module, configured to respond to a query request input by a user and determine query intent information based on the query request; a determination module, configured to filter a subset of target tools from a preset toolset based on the query intent information and determine a knowledge loading decision corresponding to the subset of target tools; a query module, configured to invoke a large language model to perform query processing based on the subset of target tools and the knowledge loading decision, and obtain query execution results; and a verification module, configured to perform rule verification processing on the query execution results and output query response information after the verification is passed.

[0007] According to one aspect of this application, an electronic device is provided, including a processor and a memory; the memory stores a computer program; when the processor executes the computer program, it implements any of the above data query methods.

[0008] According to one aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements any of the above data query methods.

[0009] One embodiment of this application provides a data query method, comprising: responding to a query request input by a user, determining query intent information based on the query request; filtering a subset of target tools from a preset toolset based on the query intent information, and determining a knowledge loading decision corresponding to the subset of target tools; invoking a large language model to perform query processing based on the subset of target tools and the knowledge loading decision, and obtaining query execution results; performing rule validation processing on the query execution results, and outputting query response information after successful validation. In this way, by filtering a subset of target tools based on query intent information and determining the knowledge loading decision, it helps reduce context token transmission overhead and server-side computational load, and the rule validation mechanism helps reduce repeated interactions caused by inaccurate results, thereby improving the processing efficiency and accuracy of data queries and helping to alleviate server-side resource consumption. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A schematic diagram of a system architecture is shown in one exemplary embodiment of this application; Figure 2 This application shows a flowchart of a method in one exemplary embodiment; Figure 3 A schematic diagram illustrating an overview of the system architecture in one exemplary embodiment of this application; Figure 4 This diagram illustrates intent-driven tool clipping in one exemplary embodiment of this application. Figure 5 This diagram illustrates zero-cost quality verification in one exemplary embodiment of this application; Figure 6 A schematic diagram of an automatic work order diagnosis process in one exemplary embodiment of this application is shown. Figure 7This illustration shows a schematic diagram of the structure of an electronic device according to one exemplary embodiment of the present application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0014] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0015] The method in one embodiment of this application can run on a terminal device or a server. The terminal device can be a local terminal device. When the method in the embodiment runs on a server, the method can be implemented and executed based on a cloud interaction system, wherein the cloud interaction system includes a server and client devices. Figure 1 The figure shows a cloud interaction system architecture diagram provided in this application. As shown, the cloud interaction system may include: a client device 10 and a server 20, wherein the client device 10 can be connected to the server 20 via a network 30.

[0016] It should be noted that the information (including but not limited to user input information, such as information entered by the user into an input box), data (including but not limited to data used for analysis, stored data, and displayed data, such as context code, all code of the current project, service pressure corresponding to operations performed on all code of the current project, and code development status of the current project), and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, the context code, operations performed on all code of the current project, and the service pressure and code development status involved in the operations in the embodiments of this application were all obtained under full authorization.

[0017] According to one embodiment of the data query method of this application, such as Figure 2 As shown, the method may include: Step S210: In response to the query request input by the user, determine the query intent information based on the query request; Step S230: Based on the query intent information, filter the target tool subset from the preset toolset and determine the knowledge loading decision corresponding to the target tool subset; Step S250: Based on the target tool subset and knowledge loading decision, call the large language model to perform query processing and obtain the query execution result; Step S270: Perform rule validation processing on the query execution result, and output the query response information after the validation passes.

[0018] According to one embodiment of this application, by filtering a subset of target tools based on query intent information and determining knowledge loading decisions, it helps to reduce context token transmission overhead and server computing load. Furthermore, the rule verification mechanism helps to reduce repeated interactions caused by inaccurate results, thereby improving the processing efficiency and accuracy of data queries and alleviating server resource consumption.

[0019] The embodiments of this application will be further described below.

[0020] In step S210, in response to the user's input query request, the query intent information is determined based on the query request. This intent recognition of the query request provides a precise basis for subsequent tool selection and knowledge loading, reducing redundant loading of irrelevant tools and knowledge, and effectively improving the efficiency and targeting of data query processing. In one example, when a user inputs the natural language message "Check user xxx's membership purchase records" through instant messaging software, the system receives and analyzes the data query request to determine that the request points to the data retrieval intent of the membership business domain, and further clarifies that the target data table associated with this query intent information is Trade_MemberShipOrder. Based on this query intent information, the system can filter out a subset of target tools related to the data query from the global toolset during subsequent processing, and initiate the corresponding business domain's hierarchical knowledge loading process, laying the foundation for subsequent precise database retrieval operations.

[0021] Optionally, a query request is used to receive data query requests submitted by users, serving as the initial input carrier to trigger subsequent intent analysis processes.

[0022] Optionally, query requests can be text messages sent by users via instant messaging software in private or group chat mode, structured work order data pushed by the alarm system through an HTTP API interface, or batch query requests automatically triggered by scheduled task instructions. Considering the differences in operational habits among different business roles within an enterprise, the input form of the above query requests can be natural language descriptions, semi-structured field combinations, or pre-encapsulated request messages. This application does not limit their specific source channels or content formats. It should be noted that after receiving a query request, the system will first convert it into a standardized text format and extract text features that can be used for keyword matching. This ensures that data query needs from multiple channels are incorporated into the same intent analysis framework and provides a standardized input foundation for subsequent semantic understanding and intent classification by a large language model.

[0023] Optionally, query intent information is intended to characterize the type of business objective that the query request points to, and is used to guide subsequent toolset trimming and knowledge base loading strategies.

[0024] Optionally, the query intent information can be a structured decision result output by a Large Language Model (LLM). Its content fields include at least the intent type, the identifier of the matched target data table, the suggested first step, and the corresponding reasoning basis. For example, when a user submits a request to investigate member purchase records, the intent type in the query intent information can be parsed as `query_data`, the matched target data table can include `Trade_MemberShipOrder` and related business data tables, and the suggested first step could be to call a tool to obtain table structure details. When the user request involves code location, the intent type can be marked as `explore_code`. It should be noted that the above classification of intent types is merely an example, and this application does not intend to limit the granularity of intent information classification. In actual implementation, it can be dynamically expanded or merged according to the business scale and the complexity of the query scenario. This query intent information serves as the decision anchor point for the intelligent query chain, directly determining the range of target subsets selected by the tool's dynamic pruning module from the global toolset, and whether the knowledge layer loading module activates the secondary knowledge loading of the corresponding business domain. This ensures the accuracy and efficiency of subsequent query processing steps from the source.

[0025] Optionally, determining query intent information aims to semantically analyze the user's input query content to clarify its corresponding business objective type and operational direction. Optionally, the process of determining query intent information may include: firstly, using a keyword matching algorithm to extract a set of candidate data table names from the query request text as an initial recall signal; then, sending this candidate set along with the original query message, knowledge base index, and a list of learned data items to a large language model for deep semantic analysis. It should be noted that the keyword matching algorithm's role is to provide high-recall candidate recommendation signals, rather than directly serving as the final decision result. This is to avoid the inaccuracy problem of pure rule matching when handling colloquial expressions or business abbreviations. Further, after receiving the above information, the large language model comprehensively analyzes the semantic features of the user message and the business attributes of the candidate data tables, outputting a structured intent analysis result, which includes at least an intent type identifier, the matched target data table name, the suggested first step, and the corresponding reasoning text. This process, through the coordinated operation of keyword matching and the large language model's decision-making, balances the recall and accuracy of intent recognition, thus providing a reliable decision-making basis for subsequent tool tailoring and knowledge loading.

[0026] In an optional implementation, determining query intent information based on the query request includes: performing keyword matching processing on the query request to obtain a set of candidate data objects; inputting the set of candidate data objects and the query request into a large language model to obtain intent analysis results; and determining query intent information based on the intent analysis results. In this way, intent routing is performed collaboratively through keyword matching and a large language model, balancing recall and precision, avoiding the limitations of pure rule matching or the biases of pure model decision-making, making intent recognition more accurate, and significantly reducing the decision-making burden of the large language model.

[0027] In one implementation, when a user inputs "Check the refund status of yesterday's member orders," the system first calls a data object retrieval scoring function to perform keyword matching on the query request. Specifically, the system extracts the keywords "member," "order," and "refund" from the user message, segments them using n-grams (n ranges from 2 to 4), and retrieves a set of candidate data objects, including a member order table, along with the matching confidence score for each object. Subsequently, the system inputs the aforementioned candidate set and the context of the original user message into a large language model. After comprehensive analysis, the large language model outputs intent analysis results, which are carried in JSON (a structured data format) and include the intent type, matched data objects, suggested initial actions, and reasoning basis. Finally, the system determines the query intent information based on this intent analysis result and completes intent routing.

[0028] Optionally, keyword matching processing aims to retrieve potentially relevant data objects from the query request, providing them as recommendation signals for subsequent routing decisions to reduce the search scope of the large language model. Optionally, keyword matching processing can be implemented through a data object retrieval scoring function. This function receives the user-input query request, performs n-gram segmentation on the request text, where n ranges from 2 to 4, generating phrase fragments of various granularities. The system compares these fragments with a pre-defined data object index, calculates semantic and literal matching scores, and then generates an ordered set of candidate data objects. It should be noted that the above description of segmentation granularity is only one example; in actual implementation, it can be adjusted according to data table naming conventions, business terminology length, or specific application requirements. Considering that enterprise databases typically contain thousands of tables, directly submitting all table information to a large language model for intent analysis would lead to extreme contextual expansion and decision-making difficulties. As a possible implementation method, a preliminary screening can be conducted using lightweight keyword matching. This can narrow down the candidate range to a few tables that are most relevant to the user's needs, and can also significantly reduce the token (smallest semantic unit) consumption and cognitive load of the large language model, making subsequent routing decisions more focused.

[0029] Optionally, besides n-gram segmentation, keyword matching can also employ precise matching based on a business terminology dictionary, semantic similarity matching based on vector retrieval, or a weighted calculation of multiple matching strategies to arrive at a comprehensive score. This application is not limited to these methods. Furthermore, after obtaining the candidate data object set, the system can set a threshold based on the matching score to filter out noisy items with low relevance, retaining only a preset number of data objects with high confidence (e.g., the top 5 or top 10) as recommendation signals. If keyword ambiguity leads to insufficient recall results, the matching conditions can be automatically relaxed or synonym expansion can be introduced to ensure recall. It should be understood that each object in the candidate data object set, in addition to containing the table name, can also include the business domain to which the table belongs, a brief functional description, or historical query frequency, thereby providing richer decision-making basis for subsequent intent analysis of the large language model.

[0030] Optionally, the candidate data object set includes a list of data objects recalled after keyword matching and their associated information, used to provide recommendation signals for routing decisions to the large language model. Optionally, the data objects in the candidate data object set can be physical tables, views, or predefined virtual tables in a database. Each candidate object typically comes with a matching score or confidence information to characterize its relevance to the user's query request. When the system inputs this set into the large language model, it can sort them from high to low according to the matching score, allowing the model to prioritize data objects with higher relevance. It should be noted that the generation of the above set not only depends on the literal matching of a single query, but can also be dynamically adjusted by combining the learned item list, the user's historical query records, or the current business domain context. For example, when the system identifies that the current session frequently involves member-related topics based on the learned item list, even if the current query keywords are relatively vague, the system can appropriately increase the matching weight of member domain-related tables. One objective of this embodiment is that by introducing a weighted candidate set, on the one hand, irrelevant data objects avoid interference with the context of the large language model, and on the other hand, it enables intent routing to take into account both historical behavior and current intent, improving the overall recall accuracy. In addition, the upper limit of the number of candidate data objects can be configured according to the actual business scale, for example, the default limit is 5 or 10, to prevent too many recommendation signals from losing the focus effect.

[0031] Optionally, the intent analysis results are output by the large language model, including intent type, matched data object, suggested first-step operation, and reasoning basis, used by the system to determine query intent information. Optionally, the intent analysis results can be carried in a data format such as JSON (a structured data format), which includes at least the intent type field, the matched data object field, the suggested first-step operation field, and the reasoning basis field. The intent type can be used to distinguish different business scenarios such as data query, learning a new table, correcting knowledge, exploring code, or exploring the unknown; the matched data object field can record one or more target tables confirmed by the model from the candidate data object set. Furthermore, in the process of determining query intent information based on the intent analysis results, the system can parse the above structured data to extract the specific intent type and associated table name, thereby providing a clear decision-making basis for subsequent data queries and problem diagnosis. If insufficient confidence or ambiguity of intent occurs, the system can also present the reasoning basis to the user or initiate multiple rounds of clarification interaction. It should be noted that the format and content of the intent analysis results are not limited to the fields mentioned above. They can also be expanded to include auxiliary information such as business domain information, estimated token (the smallest semantic unit of text) consumption, or risk warnings, depending on actual business needs.

[0032] In step S230, based on the query intent information, a subset of target tools is selected from a preset toolset, and a knowledge loading decision corresponding to the target toolset is determined. This dynamic selection of tools and matching of knowledge loading strategies based on query intent reduces the context load and token consumption of large language models, minimizes decision interference in tool selection, and improves query execution efficiency and accuracy. In one implementation, after the intent routing module outputs the query_data (data query) intent type, the tool dynamic pruning module queries a preset intent-tool mapping table and selects a first-round core tools subset (e.g., execute_sql (execute SQL query), get_table_schema (get table structure), and convert_timestamp (timestamp conversion) from 35 global tools). Simultaneously, the knowledge layering loading module determines the corresponding knowledge loading decisions: first, it loads the first-level knowledge, namely the L0 layer business domain index (approximately 200 tokens (the smallest semantic unit of text processed by the large language model)). Since it hits the member business domain, it then loads the data table summary and business terms of that domain (approximately 500 tokens) from the L1 layer, without needing to preload the L2 layer containing a complete data definition language description. In this way, the target tool subset and knowledge loading strategy are determined simultaneously, providing streamlined context support for subsequent calls to the large language model.

[0033] Optionally, the preset toolset includes various utility functions that can be called by the large language model to perform data queries, code exploration, and result output. Its specific composition is dynamically configured according to the system's business scenarios.

[0034] Optionally, the pre-defined toolset, as a globally maintained collection of utility functions, may include, but is not limited to, modules such as `execute_sql` (for executing SQL queries), `get_table_schema` (for retrieving table structures), `execute_bi_sql` (for executing BI queries), `generate_chart` (for generating charts), `export_csv` (for exporting files), `convert_timestamp` (for timestamp conversion), `parallel_query` (for parallel queries), and `search_gitlab_code`, `read_gitlab_file`, and `learn_code` (for code exploration). Each utility function in this pre-defined toolset is encapsulated in a standardized interface format, facilitating unified scheduling by the large language model through the Function Calling mechanism. It should be noted that the number and types of tools included in the preset toolset are only one example. In actual deployment, it can be expanded or tailored according to the complexity of the target business platform and user query needs. For example, special tools for data anonymization, permission verification or log diagnosis can be added. This application is not intended to limit the specific composition of the preset toolset.

[0035] Optionally, the target tool subset is a streamlined set trimmed from a pre-defined tool set according to intent type, used to expose the most relevant tool capabilities to the large language model in a single-round query. Optionally, the determination process of the target tool subset adopts a two-stage injection strategy. In the first stage, the system determines a first tool subset from the pre-defined tool set based on query intent information. For example, when the intent type is query_data (data query), only about 5 core tools such as execute_sql (execute SQL query), get_table_schema (get table structure), and convert_timestamp (timestamp conversion) are injected. This subset occupies about 700 tokens (the smallest semantic unit of text processed by the large language model) and can cover about 80% of regular query requests. During query processing, if the results returned by executed tools and the context information of the current dialogue state indicate that the user has a need for chart generation or data export, the second stage adds tools such as `generate_chart` (generate charts) or `export_csv` (export CSV files) from the preset toolset, forming a second tool subset. The first and second tool subsets are then merged to obtain the target tool subset. In this way, by combining dynamic pruning and on-demand addition, the tool selection space faced by the large language model in a single-turn interaction is effectively compressed. This reduces contextual load and avoids decision interference caused by irrelevant tools, enabling the model to more accurately call appropriate tools to complete the query task.

[0036] Optionally, the knowledge loading decision is used to determine the loading level and scope of business knowledge based on query intent information, in order to minimize the number of tokens injected into the large language model context in a single request. Optionally, the knowledge loading decision specifies the execution logic for selectively loading specific levels from a multi-layered knowledge structure. First, the first level of knowledge, L0, is loaded. This layer contains a list of business domains and an index directory of recorded queries, loading approximately 200 tokens (the smallest semantic unit of text processed by the large language model) per request to determine the business domain to which the query request belongs. After a specific business domain is hit, the second level of knowledge, L1, is loaded. This layer contains a summary of the data tables corresponding to the business domain and a description of business terms, totaling approximately 500 tokens. Based on this, the large language model actively acquires the third level of knowledge, L2, on demand. This layer contains a complete data definition language description and is only loaded when a database retrieval statement needs to be written or validated, triggered by tools such as `get_table_schema` (to obtain the table structure). In this way, through the hierarchical decision-making mechanism, the amount of knowledge injected in a single request is controlled to within about 700 tokens, which is about 90% lower than the full injection method, greatly saving the computational cost of the call, while ensuring that the model can obtain accurate table structure details when necessary to generate the correct database retrieval statement.

[0037] In an optional implementation, a target tool subset is selected from a preset toolset based on the query intent information. This includes: determining the tool associations corresponding to the query intent information based on the query intent information; determining a first tool subset from the preset toolset based on the tool associations; determining a second tool subset from the preset toolset based on the context information of the returned results of executed tool calls and the current dialog state during the execution of the query processing; and merging the first and second tool subsets to obtain the target tool subset. In this way, determining the initial tool subset through intent association and adding subsequent tools as needed during execution not only significantly reduces context length consumption but also narrows the tool selection space, reduces the probability of erroneous calls, and improves query processing efficiency and accuracy.

[0038] For example, when a user submits a question through an enterprise chat tool, the system identifies the query request as a data query intent through intent routing. Then, based on the tool associations corresponding to the intent, it determines a first subset of tools from a preset toolset, including tools for executing structured query statements and tools for obtaining table structures. After the first round of execution, based on the return results of the executed tool calls and the context information of the current dialogue state, the system further determines a second subset of tools from the preset toolset, including chart generation capabilities. The two subsets are then merged to form the target tool subset, which is delivered to the large language model for subsequent processing.

[0039] Optionally, tool associations describe the mapping rules between query intent information and necessary toolsets, dynamically pointing to the corresponding toolset based on the intent type. Optionally, tool associations can be a mapping table from intent to toolset, where data query intents correspond to more than ten tools including execute_sql (tool for executing structured queries), get_table_schema (tool for obtaining data table structure), and execute_bi_sql (tool for executing business intelligence queries), while code exploration intents correspond to code exploration tools such as search_gitlab_code (tool for searching code repositories) and read_gitlab_file (tool for reading code files). It should be noted that the above mapping content is only an example; tool associations can also include various intent types such as learning new tables, correcting knowledge, and exploring the unknown, along with their corresponding tool combinations. The number of tools associated with each intent type can be flexibly configured; for example, data query intents can be associated with six to twelve tools, and code exploration intents can be associated with three to eight tools, thus ensuring functional integrity while avoiding interference from irrelevant tools on the context window. As one possible implementation, the tool association relationship is not limited to a static mapping table; it can also be dynamically generated association rules, such as weighted recommendations based on the busyness of the business domain or the historical success rate of tool calls. In another approach, the tool association relationship can be determined collaboratively by keyword triggers and an intent classifier: when the confidence level of the intent routing output is lower than a preset threshold, the system automatically expands the scope of the first tool subset to cover more possibilities, preventing the loss of necessary tools due to intent misjudgment. The purpose of this design is to improve the coverage of complex query scenarios through redundancy while ensuring the accuracy of intent recognition.

[0040] Optionally, the first subset of tools is designed to cover the basic operations required in the initial stages of query processing, reducing the decision burden on large language models with a limited number of tools.

[0041] Optionally, the first tool subset typically consists of basic tools strongly related to the query intent. For example, in a data query scenario, the first tool subset injected in the first round could include approximately five tools such as `execute_sql` (execute structured query statement tool), `get_table_schema` (get data table structure tool), and `convert_timestamp` (timestamp conversion tool). Its text processing unit consumption is controlled to around 700 words, covering approximately 80% of regular query requests. Injecting a small number of tools in the first round not only significantly reduces the context length but also avoids cognitive overload when a large language model has to choose from dozens or more global tools. It should be noted that the specific number of tools in the first tool subset can be adjusted according to the actual toolset size and business scenario. For example, when the total number of tools expands to more than fifty, the first tool subset can be expanded to six to eight tools accordingly, but its text processing unit ratio should still be much lower than that of full injection. Optionally, the determination of the first tool subset not only depends on query intent information but can also be dynamically optimized by combining historical dialogue patterns. For example, when the same user frequently performs data export operations in recent sessions, the system can pre-include `export_csv` (an export table tool) in the first tool subset without waiting for a second round of appending. Furthermore, if the intent routing module identifies that a query request involves cross-database operations, the first tool subset can also simultaneously include the `execute_sql` tool for online distributed databases and the `execute_bi_sql` tool for offline analysis databases, thus enabling cross-source query capabilities in the first round and reducing the interaction overhead in subsequent rounds.

[0042] Optionally, the results returned by the executed tool call are used to reflect the execution status and output of the preceding tools, serving as the data basis for dynamically expanding subsequent tools.

[0043] Optionally, the returned results of executed tools can be the execution status of the previous round of structured query statements, the number of data rows, field type information, or error messages. For example, when the `execute_sql` tool returns an empty set, the system may determine that it is necessary to call the `get_table_schema` tool to reconfirm the field mapping relationship, or add `parallel_query` (a parallel query tool) to attempt multi-source retrieval; when the returned results contain a message indicating a garbled timestamp format, the system can add `convert_timestamp` (a timestamp conversion tool). The returned results not only include the tool's own output data but can also include metadata such as execution time and database connection status. This metadata helps the system determine whether diagnostic or log analysis tools need to be introduced, thereby gradually refining the composition of the target tool subset through multiple rounds of dialogue. In practical applications, the degree of structure of the returned results directly affects the efficiency of determining the second tool subset; therefore, the returned results should adopt a unified key-value pair format, including at least three fields: status code, data summary, and exception identifier, so that the rule engine can quickly parse them.

[0044] Optionally, the context information of the current dialogue state is used to record the interaction rounds, executed operations, and user-added descriptions to determine whether the range of available tools needs to be expanded. Optionally, the context information of the current dialogue state may include the number of rounds executed, user append commands in previous rounds, a list of triggered tools, and markers for incomplete subtasks. For example, in the third round of interaction, when the system detects that the user input contains keywords such as trend chart, comparison, or download, combined with the context of the `execute_sql` tool already called in the previous two rounds, the system determines that a second subset of tools such as `generate_chart` (chart generation tool), `parallel_query` (parallel query tool), or `export_csv` (table export tool) needs to be added. It should be noted that the context information is updated in real time. After each round of tool calls, the dialogue state management module re-evaluates the current context to ensure that the added tools are consistent with the user's latest requests, avoiding premature injection of redundant tools leading to wasted text processing units or premature injection leading to an increase in interaction rounds. In another approach, contextual information can also record the user's identity and role. For example, when customer service personnel and developers initiate queries for the same keywords, the system adds different subsets of second tools based on the differences in roles to adapt to their respective business needs.

[0045] Optionally, the second tool subset is added dynamically during execution based on needs, merging with the first tool subset to form a complete target tool subset. Optionally, the second tool subset can be a tool set added on demand after the first round of large language model calls. For example, when advanced needs such as generating charts, exporting data, or parallel comparison arise in the user request, the system injects tools like `generate_chart` (chart generation tool), `export_csv` (table export tool), or `parallel_query` (parallel query tool) in the second or third round. The merging operation between the second and first tool subsets can be a simple list concatenation or an ordered merging after deduplication. The merged target tool subset will replace the tool context of the previous round and be resubmitted to the large language model. This phased injection mechanism allows the large language model to focus on basic data acquisition in the initial stage, loading specialized tools only after confirming the details of the requirements, thereby reducing the pressure of single decision-making while ensuring the functional integrity of complex queries. Optionally, the triggering condition for the second tool subset can also be driven by abnormal states in the results returned by executed tool calls. For example, when the `execute_sql` tool in the first tool subset reports an error due to a missing table structure, the system triggers the second tool subset to add the `get_table_schema` tool; when the query result involves multiple related tables and single-threaded processing times out, the `parallel_query` tool is added. Furthermore, the size of the second tool subset is typically controlled to be within two to four tools to ensure that the total text processing unit consumption remains low after the additions. It should be understood that the injection order of the tools in the second tool subset can be determined based on dependencies; for example, reading the table structure should take precedence over rewriting queries based on that structure, thereby avoiding logical conflicts in tool calls.

[0046] In an optional implementation, determining the knowledge loading decision corresponding to the target tool subset includes: loading first-level knowledge and determining the business domain to which the query request belongs based on the first-level knowledge to obtain business domain information; if the business domain to which the query request belongs is determined, loading second-level knowledge corresponding to the business domain information; based on the second-level knowledge, calling the large language model to obtain third-level knowledge, and performing database retrieval based on the third-level knowledge. In this way, by loading knowledge content of different granularities in a hierarchical and progressive manner, the context bloat caused by a one-time full injection is effectively avoided, the token consumption of a single call to the large language model is significantly reduced, and the on-demand and accurate supply of knowledge is ensured.

[0047] In one implementation, upon receiving a query request, the system first loads first-level knowledge to identify the business domain to which the request belongs. After confirming a specific business domain, it loads the corresponding second-level knowledge to obtain summary information of the data tables within that domain and descriptions of business terminology. Subsequently, the system calls a large language model, and when the model requires specific query statements, it retrieves complete data definition language descriptions from third-level knowledge as needed, and performs database retrieval based on these descriptions. Thus, knowledge at different levels is injected progressively from coarse to fine, controlling the total number of tokens in a single request while ensuring the completeness and accuracy of the structural information required for the query.

[0048] Optionally, the first-level knowledge is used to carry summary index information of the business domain, aiming to quickly locate the business boundary of the query request and provide global navigation capabilities.

[0049] Optionally, the first-level knowledge can be a list of business domains and an index directory of recorded queries. This first-level knowledge is preloaded into the context of the large language model for each request, occupying approximately 200 tokens. It's important to note that this first-level knowledge does not contain the complete structure of specific data tables. Instead, it provides enumerated identifiers for business domains such as membership services, content payment, and user accounts, enabling the system to initially define the knowledge boundaries of the query request. In practical applications, when a request to query a user's membership status is received, the first-level knowledge can help identify that the request belongs to the membership service domain, thereby triggering the targeted loading of subsequent second-level knowledge. In other words, the first-level knowledge is equivalent to a lightweight knowledge map. Its information density is carefully designed to achieve rapid business domain matching with extremely low token overhead, avoiding the premature injection of irrelevant domain knowledge.

[0050] Optionally, considering the differences in the granularity of business domain division across different platforms, the first-level knowledge, in addition to the aforementioned preset business domain list, can also be a dynamic set of topics generated through adaptive clustering based on historical query logs. For example, in a content community platform, the first-level knowledge can be further subdivided into subdomains such as creation and publishing, social interaction, and monetization, or it can be organized according to the physical division of the data source (such as different instance clusters of a distributed database). To avoid the problem that static lists cannot cover new business domains, the first-level knowledge can also include frequently occurring query topics and their relevance scores that have emerged recently. When a query request cannot match a traditional business domain, the system can classify it into a newly added extended domain based on semantic similarity. One objective of this embodiment is that, through this flexible and scalable index design, on the one hand, the completeness of the knowledge system is ensured, and on the other hand, the lexical consumption is kept at a low level.

[0051] Optionally, the second level of knowledge is used to carry summaries of data tables and definitions of terms within the business domain, aiming to provide a structured reference for the table structure hierarchy within the domain.

[0052] Optionally, the second-level knowledge may include, but is not limited to, a summary of the data table names under the business domain, descriptions of core field enumeration values, and brief definitions of business terms. As one possible implementation, when the first-level knowledge determines that the query request belongs to the member service domain, the system immediately loads the corresponding second-level knowledge for that domain. This includes summaries of tables such as the member order information table and the member benefits information table, as well as descriptions of business terms such as validity period and automatic renewal status. The amount of information in this second-level knowledge is typically controlled to approximately 500 tokens. Its field-level descriptions are sufficient for a large language model to understand the relationships between tables, while avoiding the premature injection of the entire data definition language (DDL) description of the entire table into the context. One objective of this embodiment is that by loading the second-level knowledge only after the first-level knowledge has been hit, it prevents the waste of knowledge from missing domains and provides precise navigation for subsequent on-demand acquisition of third-level knowledge, thereby achieving progressive convergence of knowledge supply.

[0053] Optionally, Level 3 knowledge is used to carry a complete data definition language description, aiming to provide a precise table structure basis when writing query statements for large language models.

[0054] Optionally, the third-level knowledge can be the complete table creation statement and field details actively retrieved on demand by the large language model before performing database retrieval operations by calling a table structure retrieval tool. Unlike the full preloading of first- and second-level knowledge, third-level knowledge adopts a triggered loading strategy, dynamically injecting context only when the model decides to access a specific data table. For example, when the large language model needs to query the member order information table, it calls the table structure retrieval tool to obtain the complete table creation statement, primary and foreign key constraints, index distribution, and field comments of the table, thereby accurately generating an executable structured query language. It should be noted that the above data definition language (DDL) description is not limited to a single table structure, but can also include view definitions or cross-table join mappings returned by the database metadata service; this application is not limited to this. Furthermore, since the third-level knowledge is loaded only when necessary, the overall knowledge injection volume of a single request is effectively constrained, significantly reducing the context processing burden of the large language model.

[0055] In an optional implementation, the first-level knowledge includes a list of business domains and an index directory of recorded queries; the second-level knowledge includes data table summaries and business terminology descriptions corresponding to the business domain information; and the third-level knowledge includes data definition language descriptions corresponding to database retrieval actions. By configuring the knowledge content at different levels differently, the system can load business domain indexes, table summaries, and complete data structures on demand, thereby effectively reducing the amount of data loaded into a single context of a large language model and improving query location efficiency.

[0056] For example, Level 1 knowledge can include a list of business domains such as "user domain," "order domain," and "content domain," as well as a question and answer index directory corresponding to the frequently queried "member purchase records." Level 2 knowledge is loaded after the user domain is hit, including field summaries of the user basic information table (such as user ID, registration time, and account status) and brief explanations of business terms such as "account suspension" and "account cancellation." Level 3 knowledge is retrieved on demand through tool interaction. For example, when performing a retrieval action targeting the order table, the large language model actively obtains the complete data definition language description of the order table to understand the field types, constraints, and foreign key relationship details.

[0057] Optionally, the business domain list is used to enumerate the names of the business sectors covered by the system, aiming to define the business boundaries for query requests and guide subsequent knowledge loading.

[0058] Optionally, the aforementioned business domain list can be a collection of identifiers for multiple business segments divided according to product lines or functional modules, such as including but not limited to user domains, membership domains, transaction domains, content domains, or risk control domains. It should be noted that the hierarchical division between business domains does not necessarily have to adopt a fixed tree structure; it can also be flattened or cross-labeled according to the actual database table affiliation. One objective of this embodiment is to enable the system to quickly determine the query direction at the initial stage of receiving a query request by using the business domain list as part of the first-level knowledge, without having to expand all business knowledge at once. In practical applications, when a query request involves overlapping content from multiple business domains, the business domain list can also be used to determine loading priorities, such as prioritizing the loading of second-level knowledge corresponding to business domains with higher hit frequencies, thereby improving the response speed of knowledge hits and reducing the interference of irrelevant information on the context of the large language model.

[0059] Optionally, the index directory of recorded queries is used to store location information of historical question-answer pairs, aiming to reuse past experience and speed up response when hitting high-frequency queries.

[0060] Optionally, the aforementioned index directory of recorded queries can be a fast retrieval table built for historical user queries and their corresponding standardized responses. It should at least contain the keyword signature of the query question, the relevant business domain tag, and index pointers to the knowledge block storage locations. Considering the high repetition rate of queries in actual business operations, maintaining this index directory allows the system to quickly determine whether the current query is a high-frequency question during the first-level knowledge loading stage. If so, it can further load the corresponding historical response template or a simplified knowledge fragment, thereby avoiding repeatedly triggering the large language model to perform the complete reasoning and generation process. In this process, the index directory can be maintained not only by business domain but also by time period or query popularity. It should be noted that the update frequency of this index directory can be set according to the business fluctuation cycle, such as incremental merging by day or week, to ensure that the index content always reflects the latest high-frequency query patterns.

[0061] Optionally, the data table summary is used to describe the composition and meaning of each table's fields with concise metadata, aiming to provide the model with table-level understanding information and reduce structure injection overhead. Optionally, the aforementioned data table summary can be a structured summary extracted from all or part of the data tables within a specific business domain. It includes, on the one hand, the name of the data table and the main business entity type it stores; on the other hand, it reflects the enumerated value range of key fields or the identifier of related tables. For example, in the membership business domain, the data table summary could include a summary of the order table as "stores member purchase orders, with key fields including order number, user identifier, order time, order status (pending payment / paid / refunded) and its related fields with the benefits table." To avoid the large language model blindly guessing field semantics when lacking table structure context, the aforementioned data table summary can be embedded into the context of the large language model as a fixed text block in the early stages of interaction, or it can be loaded as a vectorized fragment after keyword filtering. Furthermore, in terms of loading order, the system can prioritize loading data table summaries with high matching degrees based on the table name matching degree mentioned in the query request, in order to quickly establish knowledge anchors corresponding to the query intent. This embodiment, by limiting the granularity of the summary, covers the differentiated information needs in multi-table scenarios on the one hand, and avoids the premature injection of complete data definition language descriptions on the other hand, thus effectively balancing context compression and semantic completeness.

[0062] Optionally, the aforementioned data table summaries can be dynamically trimmed or prioritized based on the focus of the query request. Specifically, when a query request explicitly points to order status, the system can prioritize loading the field summaries related to order status, while delaying or temporarily omitting the loading of extended attribute fields stored in the table (such as marketing channel source and discount code information). In other words, the data table summaries can not only be statically organized by business domain but also dynamically focused based on the semantic focus of the query intent, thereby ensuring knowledge coverage while further compressing the amount of text loaded in a single request. If a query request involves multiple data tables, the aforementioned data table summaries can be loaded in parallel as independent text fragments, and the large language model can automatically select and reference them during subsequent inference stages. It should be noted that the precision of the field descriptions included in the data table summaries can be flexibly adjusted according to business complexity and is not limited to a fixed description template.

[0063] Optionally, business terminology descriptions are used to explain the proprietary names and meanings of data within the business domain, aiming to eliminate the model's misunderstanding of internal naming conventions. Optionally, these business terminology descriptions can be targeted explanatory texts written for internally defined business concepts, state enumeration values, or abbreviations, aiming to transform the internally accepted business meanings into standardized semantic units understandable by the large language model. In the enterprise business domain, terms such as "pending settlement," "cleared," and "outstanding" correspond to specific financial processing stages, and frequently used abbreviations in table name fields, such as user unique identifiers or standard inventory unit identifiers, also need corresponding Chinese explanations. To avoid mismatches or incorrect filtering of conditions by the large language model when generating search statements due to abbreviation ambiguity or business jargon, the above mapping relationships can be organized into key-value pairs or embedded vector fragments and stored in the second-level knowledge. Furthermore, when such business terms are identified in a query request, the system can first map them to standard field names in the database before submitting them to the large language model for search statement generation, thereby reducing information loss during semantic conversion and improving the accuracy of query intent restoration.

[0064] Optionally, the data definition language description is used to provide the structure definition and field metadata of the target table, which is intended to support the generation of accurate retrieval statements and the execution of compliant queries.

[0065] Optionally, the aforementioned data definition language description can be a complete metadata set containing elements such as the table creation statement, field names, field data types, length limits, default value settings, primary and foreign key constraints, and index configurations. This description is typically retrieved by the system at runtime from the database metadata repository through a specified utility function, rather than being directly injected into the context of the large language model during the first round of interaction. In a specific loading scenario, when the large language model determines, based on its second-level knowledge, that a retrieval statement needs to be generated for the "user order table," it initiates a utility call to obtain the complete data definition language description of the table in real time, thus clarifying details such as the order identifier field being a long integer and not null, and the order status field being an enumeration type with a finite set of values. Based on this, the large language model can not only select the correct fields and functions when generating retrieval statements, but also determine whether fields support null value filtering or range queries based on constraints. It should be understood that the level of detail in the data definition language description can be adapted to the complexity of the table structure. For wide tables with more than a preset threshold of fields, field metadata can be returned in batches.

[0066] Optionally, the acquisition method of the aforementioned Data Definition Language (DDL) description is not limited to a single-table retrieval. In handling complex join queries, the large language model can initiate multiple tool calls sequentially to obtain the complete structure definitions of the main table and related sub-tables. Considering the possibility of field naming conflicts in join queries, the system can append table alias suggestions or namespace prefixes to the returned DDL description. For example, adding a default alias "t_order" to the order table and a default alias "t_user" to the user table, so that the large language model can clearly define field ownership when constructing multi-table join statements. If the target data table has sharding rules in a distributed database environment, the DDL description can also include sharding key information and a routing rule summary, enabling the large language model to understand under what conditions additional sharding suffixes are needed. It should be noted that the above-mentioned methods of adding aliases and routing information are only optional enhancements and not necessary conditions for generating accurate retrieval statements.

[0067] In step S250, based on the target tool subset and knowledge loading decision, the large language model is invoked to execute query processing, and the query execution result is obtained. In this way, by driving the large language model to execute query processing through the pre-prepared target tool subset and knowledge loading decision, accurate feedback is obtained from natural language query requests after several rounds of interaction, while compressing context overhead, thus improving the overall execution efficiency of data query and business diagnosis. In one implementation, the system injects a pruned target tool subset and a knowledge loading decision consisting of a first-level business domain index and a second-level data table summary into the large language model. Based on this, the large language model determines that it needs to first call the table structure acquisition tool to confirm the field types and enumeration definitions of the target data table, and then generates a precise retrieval statement based on the returned structure information and executes the database query. After one or two rounds of function call interaction, the query execution result containing the target business data is obtained, and the system waits to enter the next processing stage.

[0068] Optionally, query processing is used to complete multiple rounds of data retrieval based on a pruned subset of tools and hierarchical knowledge through function calls of a large language model to obtain query results.

[0069] Optionally, query processing can be a multi-round interactive process driven by a large language model through a function calling mechanism. Specifically, in the first round of calls, the system provides the large language model with a dynamically pruned subset of target tools and contextual information determined by a three-layer progressive knowledge loading decision. Based on the user's query intent analysis, the large language model autonomously decides to call at least one tool function. For example, it might first call the table structure to obtain tools to confirm the data definition language description, and then generate and execute a structured query statement based on the returned field information. During the multi-round interactions, the large language model dynamically adjusts the tools and query parameters to be called subsequently based on the results of the executed tool calls and the contextual information of the current dialogue state, until the business data that satisfies the query request is obtained. Furthermore, when a query request contains multiple independent sub-query tasks, query processing can also include splitting the query request into multiple sub-query requests and calling sub-agents driven by the large language model to execute their respective query processing in parallel. Finally, the results of each sub-execution are aggregated to form a complete query execution result, thereby improving response efficiency and data coverage in complex query scenarios.

[0070] Optionally, the query execution result may include at least one of the following: single-table records, multi-table related datasets, sub-agent aggregated data, and diagnostic conclusions after comprehensive analysis. Optionally, the query execution result may not only be the raw record set obtained from a single database retrieval, but also a structured response generated by a large language model based on logical reasoning through multiple rounds of tool call feedback. In one implementation, when a user requests to query the benefit status of a member, the query execution result may include the purchase record sub-execution result extracted from the order table and the validity period sub-execution result extracted from the benefit configuration table. The main agent aggregates the above sub-execution results to generate a comprehensive query response information including member level, effective period, and remaining benefit count. In another implementation, when the query process involves negative conclusions, the query execution result may also include cross-validation data from at least two related data tables to ensure that negative conclusions such as unpaid or unreceived are supported by multi-source data. It should be noted that the specific presentation format of the query execution result can be dynamically determined according to the query intent; it can be a dataset displayed in tabular form or a diagnostic description refined with natural language, thus catering to the data reading needs of both technical and non-technical personnel.

[0071] In an optional implementation, based on a subset of target tools and knowledge loading decisions, a large language model is invoked to perform query processing, including: determining whether the query request contains multiple independent sub-query tasks; if it is determined that the query request contains multiple independent sub-query tasks, splitting the query request into multiple sub-query requests; for each sub-query request, invoking a sub-agent driven by the large language model to perform query processing in parallel, obtaining sub-execution results corresponding to each sub-query request; and summarizing the sub-execution results to obtain the query execution result. In this way, by splitting complex queries into independent sub-query tasks and driving sub-agents to process them in parallel, not only can the overall time consumption in multi-task scenarios be reduced, but also the contextual interference of single-threaded sequential execution can be eliminated, thereby effectively improving the processing efficiency of complex data queries and cross-comparisons.

[0072] In one implementation, a user inputs a query request via an enterprise chat tool: "Compare yesterday's C2C order volume with yesterday's total content payment revenue." The system parses the query and identifies two independent sub-query tasks: Task 1 is to count yesterday's C2C order volume, and Task 2 is to summarize yesterday's content payment revenue. The system splits the original query request into sub-query request A and sub-query request B, and launches sub-agents A and B respectively. Sub-agent A, carrying the first-level knowledge layer table summary knowledge of the order domain, invokes a database query tool to retrieve the order table; sub-agent B, carrying the first-level knowledge layer table summary knowledge of the revenue domain, invokes a business intelligence analysis tool to retrieve revenue data. The two sub-agents run in parallel within independent sessions, obtaining sub-execution results A and B respectively. The main agent summarizes the above sub-execution results, generates a final query execution result containing comparison data for the two metrics, and returns it to the user. The average time taken for the entire process is significantly reduced compared to serial processing.

[0073] Optionally, mutually independent subquery tasks are designed to represent decoupled, parallel-execution subtask units, dynamically determined based on semantic relationships. These subquery tasks can be query units divided based on the data source dimension, such as query operations targeting different business domain data tables or different database instances; or they can be query units divided based on statistical indicators, such as simultaneously calculating total order volume and total refund amount. It should be noted that the independence between these tasks is primarily determined by the overlap between data objects and retrieval conditions: if the table sets operated on by two subtasks have no intersection and their filtering conditions are mutually independent, they are considered mutually independent subquery tasks that can be executed in parallel. Furthermore, the number of tasks is not limited to two; in actual implementation, it can be split into three, four, or even more subtasks depending on the complexity of the query request. The system presets a maximum parallelism threshold to avoid excessive concurrency leading to excessive data source load. To avoid misjudgment, after initial identification, the system will also perform a syntax-level comparison of the query conditions of each subtask to confirm the absence of implicit related field constraints before proceeding to the subsequent splitting process.

[0074] Optionally, considering that user query requests may contain seemingly independent but actually data-dependent task combinations, to avoid subsequent sub-agent execution anomalies due to missing preceding results, as a possible implementation, the system can also attach dependency tags to each sub-query task during the judgment process. For example, when the first sub-task needs to calculate "the number of new users yesterday" and the second sub-task needs to calculate "the conversion rate of new users yesterday," the second sub-task actually depends on the user group output by the first sub-task as input conditions. The two do not constitute mutually independent sub-query tasks, and the system marks them as having a dependency relationship and converts them into serial execution or merges them into a single task. It should be understood that mutually independent sub-query tasks can also be divided according to time range. For example, "querying the daily order volume of the past seven days" can be split into seven parallel sub-tasks queried by day, and each sub-task does not interfere with each other in terms of data. One objective of this embodiment is that, through precise independence judgment logic, on the one hand, it can maximize the resource utilization of parallel execution, and on the other hand, it can prevent data inconsistency or empty results caused by the omission of dependencies.

[0075] Optionally, a subquery request is used to carry a split individual query task, which carries a subset of tools and knowledge-loading decisions for the sub-agent to execute.

[0076] Optionally, a subquery request can be a natural language text fragment containing complete query semantics, or a standardized query statement reconstructed by injecting specific data object constraints into the original query request. In addition to the original user intent, the subquery request may also contain execution context information automatically attached by the system, such as specifying the target tool subset number to be invoked by the subtask, the pre-loaded business domain knowledge level identifier, and the expected return field type. It should be noted that the above description of the form of the subquery request is only one example, and this application does not intend to limit its data structure. In actual implementation, the subquery request can exist in the form of a structured object, encapsulating fields such as query text, a list of candidate data objects, dependency flags, and timeout. This application embodiment does not limit this. Furthermore, to enable the sub-agent to efficiently understand the business meaning of the subquery request, the system can also automatically associate the corresponding first-level knowledge layer table summary knowledge during the subquery request generation stage, thereby shortening the understanding time of the sub-agent.

[0077] Optionally, the sub-agent is driven by the large language model and executes subquery requests in an independent session to achieve multi-task parallel processing. Optionally, the sub-agent can be an isomorphic but isolated inference instance with its own independent context memory space and tool invocation permissions. In addition to the core tools required for query execution, the sub-agent can also include auxiliary tools dynamically added based on the sub-task type. For example, when the subquery involves time series comparison, a trend chart generation tool can be added; when the subquery involves data export, an export table tool can be added. Considering that the data sources for different sub-tasks may differ significantly, as a possible implementation, each sub-agent can load different data definition language contexts and business terminology libraries during initialization based on the data object belonging to the subquery request, thereby avoiding database query statement generation errors caused by mixed contextual knowledge. One objective of this embodiment is that by configuring a minimal set of necessary tools and knowledge packages for each sub-agent, the token consumption of the large language model can be reduced, and the decision space during tool selection can be reduced, enabling the sub-agent to generate query statements more accurately in an independent session and improving the success rate of a single call.

[0078] Optionally, the number of sub-agents is usually consistent with the number of independent sub-query tasks. However, in some high-concurrency scenarios, the system can also launch multiple sub-agents to compete for execution of the same sub-query request, and select the first sub-execution result that returns and passes verification as the valid output. To avoid blocking the overall query process due to timeout or call exception of a sub-agent, the above method can also set an independent timeout monitoring mechanism and exception circuit breaker strategy for each sub-agent: if a sub-agent does not return a result within a specified time, or fails to call the tool multiple times consecutively, the system automatically terminates the sub-agent and reports an exception flag to the main agent. The main agent decides whether to abandon the sub-task, adjust the query conditions and re-dispatch it, or downgrade it to a coarser data aggregation strategy according to the preset retry rules. It should be noted that the running environment of the sub-agents can be different processes on the same computing node, or distributed deployment on different nodes. This application does not limit its physical deployment form. That is to say, in practical applications, sub-agents can be implemented in the form of containerized instances or lightweight threads, and their specific technical implementation methods can be flexibly configured according to the system's resource conditions.

[0079] Optionally, the sub-execution result represents the intermediate data returned by the sub-agent after completing the sub-query request, and is stored in a structured format for aggregation.

[0080] Optionally, the sub-execution result can be a collection of data tables returned by a structured query, a natural language analysis fragment generated by a large language model, or output in binary or text format such as chart files or log summaries. In addition to the data returned by the original query, the sub-execution result can also contain data source traceability information, such as the name of the queried database table, execution timestamp, number of data rows, and a summary identifier for quality verification. This information helps the main agent perform data source verification and consistency comparison during the aggregation phase. It should be noted that the above description of the sub-execution result is only one example, and this application does not intend to limit its data format. In actual implementation, if the sub-agent encounters an error or returns an empty result during execution, the sub-execution result can also encapsulate an exception status code and error message text. When the main agent identifies the exception flag during aggregation, it can trigger a local supplementary retrieval or retry mechanism without rolling back the entire query process to the initial state.

[0081] Optionally, the aggregation function integrates the results of each sub-execution into a unified query result, which is then processed by the main agent according to merging rules. Optionally, aggregation can involve merging numerical fields from multiple sub-execution results according to arithmetic rules, such as summation, averaging, or calculating ratios; it can also involve concatenating multiple sub-tables into a single wide table according to a specified dimension; or it can integrate the text analysis conclusions of each sub-agent into a coherent comprehensive diagnostic report. Considering that the data returned by different sub-agents may have differences in time granularity or statistical caliber, to avoid errors in the final conclusion due to data alignment mistakes, as a possible implementation, the main agent can first perform a consistency check on the data patterns of each sub-execution result during aggregation, confirming that the field names, data types, and record ranges returned by each subtask meet expectations before performing the merging operation. Furthermore, if the sub-execution results contain contradictory negative conclusions, such as one sub-agent determining "order not paid" while another determines "refund record exists," the main agent can automatically trigger a cross-validation process during the aggregation stage, adding queries to related tables to eliminate the contradiction. One objective of this embodiment is to ensure logical consistency of the final output after multi-source parallel queries through a structured aggregation mechanism, and to enhance the credibility of negative conclusions by leveraging the data complementarity between subtasks.

[0082] In an optional implementation, before splitting the query request into multiple sub-query requests, the method further includes: determining the dependencies between each sub-query task based on semantic association information in the query request; and determining the execution order information of each sub-query request based on the dependencies. This way, by pre-analyzing the dependencies between sub-query tasks and determining the execution order, logical conflicts and data competition during parallel execution can be effectively avoided, improving the accuracy of multi-task query results and system reliability. In one implementation, when a user inputs a query request of "counting the number of paid users who completed the course yesterday," the system identifies that the request involves two data sub-tasks: "querying the list of paid users yesterday" and "querying the people among these users who completed the course." Since the latter task requires the output of the former task as a filtering condition, there is a sequential dependency between the two. After determining this dependency based on semantic association information (e.g., the referential association established by the keywords "among them" and "these"), the system sets the former task as a higher priority and executes it first. The latter task is then started only after the former returns the user identifier list, thus avoiding data loss or logical errors caused by the two sub-agents blindly running in parallel.

[0083] Among them, semantic association information is used to characterize the degree of logical reference and content coupling of different subquery tasks in the query request text.

[0084] Optionally, semantic association information can be extracted from user-input natural language queries in various ways. For example, when referential terms (such as "these users," "the aforementioned orders," or "the group") appear in the query, the system can identify the preceding object to which the current subtask refers through coreference resolution, thereby establishing implicit associations between tasks. In addition, semantic association information can also include the syntactic modification relationships between subtasks, such as whether the time range or conditional constraints in one subtask are inherited from another. If they share the same business object or the same limiting conditions, their association is correspondingly strengthened. It should be noted that the extraction of semantic association information is not limited to a single technical means; it can also be achieved through rule-based keyword matching, dependency parsing, or the semantic understanding capabilities of large language models. By explicitly defining semantic association information, the system can predict which tasks must maintain sequential consistency at the data level before splitting subqueries, thereby avoiding wasted computational resources or incorrect results due to logical coupling in subsequent parallel execution phases.

[0085] Among them, the dependency relationship is used to describe the sequential constraints and data reference hierarchy of each subquery task in the execution sequence.

[0086] Optionally, dependencies can be of various types, including but not limited to data dependencies, control dependencies, and business rule dependencies. Data dependencies refer to situations where a subsequent subquery task requires the output of a previous subquery task as input. For example, first querying the member order table to obtain a list of user identifiers, and then using that list to query the member benefits table to determine specific service content. Control dependencies refer to situations where the execution of one subquery task depends on the execution status or intermediate conclusion of another subquery task. For example, only after confirming that a user has unpaid orders is the query action of the payment transaction table triggered. Business rule dependencies typically manifest as inherent sequential constraints in the business process. For example, according to internal data governance standards, the online distributed database in the production environment must be queried first to obtain the real-time status, and then historical trend comparisons must be performed in an offline analysis database based on that status. To avoid empty sub-agents or data inconsistencies due to incomplete dependency identification, the above dependencies can be structured and recorded in the form of a directed acyclic graph during the decomposition phase, with each subquery request as a node and dependency edges indicating the order of execution. It should be understood that determining dependencies does not require exhausting all potential weak associations; it only requires ensuring that the sequential constraints between strongly coupled subtasks are fully captured.

[0087] The execution order information is used to prioritize and schedule subquery requests based on established dependencies. Optionally, the execution order information can be automatically derived by the system based on the aforementioned dependencies. It includes not only the relative order of subquery requests but also concurrent scheduling identifiers and synchronization wait points within the parallel group. For example, when dependencies indicate that subtasks A and B do not depend on subtask C and there is no cross-coupling between them, these three subquery requests can be marked as being initiated in parallel in the same batch. For subtasks D, E, and F with chained data dependencies, they are assigned increasing priority numbers to ensure that each level of sub-agent only starts execution after the preceding level returns valid data. Furthermore, the execution order information can also embed timeout circuit breakers and retry strategies. If a preceding subquery fails due to a database connection error, subsequent tasks that depend on the result will be paused and trigger an overall retry or degradation process to avoid unnecessary computation consuming parallel resources. It should be noted that the generation process of execution order information can be dynamically calculated by the main intelligent agent at the beginning of each session, or it can be pre-configured based on similar query patterns accumulated in historical work order scenarios. This application does not limit its specific generation time and maintenance method.

[0088] In step S270, rule validation processing is performed on the query execution result, and the query response information is output after the validation passes. By performing rule validation processing before output, not only can numerical illusions and logical omissions be effectively intercepted, but the accuracy of the response can also be guaranteed without additional model call overhead, thereby significantly improving the reliability of the intelligent query system. In one implementation, after the large language model completes the query processing and generates a preliminary answer to the user's question, the system sends this preliminary answer as the query execution result to the rule validation processing stage. The validation stage performs multi-dimensional verification of the answer based on preset rules. Only after all validations pass will the system return the answer as the formal query response information to the user interface or call interface. If the validation fails, a correction process is automatically triggered for supplementary processing, all without the user's awareness, thus ensuring the accuracy and reliability of the final output content.

[0089] Optionally, rule validation checks the query execution results to ensure the accuracy and completeness of the output without increasing overhead. Optionally, the above rule validation can be implemented using pure rule logic, aiming to conduct multi-dimensional reviews of the query execution results generated by the large language model to avoid directly returning incomplete or incorrect answers to the user. As one implementation, rule validation may include answer completeness validation to identify whether the generated answer is too brief or omits key query results; as another implementation, rule validation may include numerical authenticity validation to verify whether the statistical figures appearing in the answer have corresponding tool call results as a basis; further, rule validation may include conclusion reliability validation to check whether a sufficient number of data objects have been retrieved to support a negative conclusion. It should be noted that the above rule validation does not require re-calling the large language model; it relies entirely on preset rule logic execution, resulting in extremely low single-validation time and effectively improving the accuracy and reliability of query response information without increasing additional computational overhead.

[0090] In an optional implementation, rule validation processing is performed on the query execution results, including: determining whether there is a negative conclusion in the query response information based on preset negative keywords; if a negative conclusion is determined to exist, determining whether the number of data objects involved in the database retrieval action meets a preset quantity threshold; if the number does not meet the preset quantity threshold, triggering a supplementary database retrieval action, and updating the query response information based on the execution result of the supplementary database retrieval action. In this way, by triggering multi-table cross-validation for negative conclusions, the risk of misjudgment caused by single-table queries is avoided, significantly improving the accuracy and reliability of data diagnostic conclusions.

[0091] In practical applications, when the agent generates the negative conclusion "This user has no unpaid orders," the quality verification module first identifies the negative keyword "does not exist." It then checks that this conclusion is based solely on the order form table, involving only one data object, which does not meet the preset threshold of 2. Therefore, it automatically triggers supplementary searches of the payment transaction record table and the refund table, updating the conclusion after integrating evidence from multiple tables. Through this mechanism, the system effectively eliminates false negatives caused by missing data from a single table, ensuring the credibility of the diagnostic conclusion. Optionally, preset negative keywords are used to identify negative conclusions to trigger cross-validation; these keywords must include at least "does not exist," "not received," and "expired."

[0092] Optionally, the preset negative keywords can be a negative word library maintained by the system, or a set of semantic tags dynamically expanded according to business scenarios. Specifically, negative keywords not only include explicit negative words such as "none," "not," "does not exist," "not received," and "expired," but can also cover phrases with implicit negative semantics, such as "no record found," "not matched," and "empty returned." To avoid missed detections due to differences in business domains, as a possible implementation method, the above negative keywords can be grouped and configured according to business domains. For example, the customer service ticket domain focuses on transaction-related negative words such as "not paid" and "not shipped," while the user authentication domain focuses on status-related negative words such as "not verified" and "not bound." If keyword conflicts occur, such as "payment not successful" containing both negative words and business status words, a priority rule can be set to prioritize the negative conclusion. It should be noted that the number and specific entries of negative keywords are not limited to the above examples. The system can automatically expand based on manually corrected negative conclusion samples from historical question-and-answer records to continuously improve the recognition coverage.

[0093] Optionally, the matching method for preset negative keywords can be at least one of exact matching, prefix matching, or regular expression matching. Considering that query response information is usually generated by a large language model based on the search results, and its wording has a certain degree of flexibility, in order to avoid omitting variant expressions, as a possible implementation, the system can adopt a multimodal matching strategy: first perform exact matching, and then perform fuzzy matching on the remaining text, such as identifying similar negative words through edit distance calculation. Furthermore, if the query response information contains compound sentences or multiple sub-conclusions, the above matching process can also be combined with sentence decomposition to determine whether each sub-conclusion contains negative keywords, thereby accurately locating the target segment that needs cross-validation. It should be understood that the update frequency and trigger sensitivity of preset negative keywords can be dynamically adjusted by the administrator according to business peak and valley periods, and this application does not limit its specific implementation form.

[0094] Optionally, a negative conclusion refers to a judgment result in the query response information indicating missing data or non-existent status, presented in the form of a negative statement or zero-value statistics. Optionally, a negative conclusion can manifest as a negative judgment in various business scenarios, such as "This user did not purchase a membership," "No new orders were placed yesterday," or "No refund records exist within the query scope." Considering that a negative conclusion in a data diagnostic scenario signifies some kind of anomaly or exclusionary judgment, an error could lead to a erroneous reverse perception by the decision-maker, with a potential risk even higher than a positive error. As a possible implementation, the system not only verifies negative conclusions in the final answer but also monitors negative assertions appearing in intermediate reasoning steps. For example, when the agent arrives at "This user has not bound a mobile phone number" in multiple rounds of queries and uses this as the basis for subsequent reasoning, the aforementioned cross-validation mechanism will intervene in advance to verify whether the assertion has been confirmed by at least two association tables, thereby preventing erroneous assumptions from being amplified in subsequent reasoning chains.

[0095] Optionally, the process of identifying negative conclusions can also be aided by combining the confidence level or inference path output by the large language model. In addition to relying on preset negative keywords for text-level matching, the system can also analyze the sequence of tools called by the agent when generating the answer. If the tool returns an empty set and the agent outputs a negative conclusion accordingly, the conclusion is automatically included in the cross-validation queue. To avoid missed detections due to semantic understanding bias, the above mechanism can also set a fallback rule: as long as the query response information contains statistical items with a value of zero, or involves core negative semantics such as "none" or "empty," it is considered that a negative conclusion exists. It should be understood that the importance of negative conclusions varies in different business scenarios. The system can configure differentiated quantity thresholds for them, requiring higher table quantity verification standards for financial negative conclusions to match business sensitivity.

[0096] Optionally, a preset quantity threshold is used to determine whether the data source on which the negative conclusion is based is sufficient. Its value can be dynamically set according to the business scenario and the density of data table associations. Optionally, the preset quantity threshold can be a fixed value, such as 2 or 3, or it can be an adaptive parameter dynamically adjusted according to the business domain to which the query request belongs. In one implementation, for customer service ticket diagnosis scenarios, considering that negative conclusions need to exclude multiple possibilities such as abnormal user status, unpaid orders, and no refund records, the system sets the preset quantity threshold to 2, requiring that a negative conclusion must be based on the retrieval results of at least two data tables to be valid. If the database retrieval action only involves a single data table, such as querying only the order table and obtaining "no unpaid orders," the verification rule automatically determines that the evidence for this conclusion is insufficient and triggers a supplementary retrieval. It should be noted that the specific values ​​of the above thresholds are only examples. In actual deployment, a tiered configuration can be made according to the logical dependency strength between data tables. For example, the negative conclusion threshold involving financial settlement can be set to 3, while the negative conclusion threshold involving content queries can be set to 2, to balance accuracy and retrieval efficiency.

[0097] Optionally, the preset quantity threshold can also be set with reference to the hierarchical structure and time dimension of the data source. As a possible implementation, the system not only counts the number of physical tables involved in the retrieval, but can also treat multiple queries on the same logical table across different time slices as multiple independent data object sources. For example, if today's order table and historical order table are queried separately, even if their physical structure definitions are the same, they can be accumulated as two data objects during cross-validation. Furthermore, to avoid threshold invalidation due to overly fine splitting, the system can also introduce a weighting mechanism: the main business table is counted as 1 unit, and related auxiliary tables are counted as 0.5 units. When the weighted sum reaches the preset quantity threshold, the validation is considered successful. It should be understood that the threshold calculation logic can take many forms. This application aims to ensure that the negative conclusion is supported by multi-source data and does not limit the specific details of the counting method.

[0098] Optionally, supplementary database retrieval is intended to perform additional retrieval operations when there is insufficient evidence to negate the conclusion, in order to obtain supporting data required for cross-table verification. Optionally, supplementary database retrieval can be automatically derived by the quality verification module based on the missing data dimensions of the negation conclusion. For example, when the system determines that the negation conclusion "this order has not been paid" is based solely on the order table, the verification module will automatically trigger a supplementary query on the payment transaction table to confirm whether there are any missing records due to asynchronous payments or third-party payment callback delays. As a possible implementation, the data retrieval statement for the supplementary retrieval can be generated using a pre-defined association rule template, which defines the association fields and filtering conditions between the main table and the auxiliary table, ensuring that the supplementary query can quickly focus on the relevant data subset. It should be noted that the supplementary database retrieval action is not limited to a single append; if the preset quantity threshold is still not met after the supplementary retrieval, the system can iteratively execute multiple rounds of supplementary queries until sufficient cross-validation evidence is obtained or the maximum number of retries is reached.

[0099] Optionally, the scope of supplementary database retrieval actions can be extended to external data sources or caching systems. Considering that enterprise internal data is distributed across different types of storage media in actual business operations, such as distributed databases, offline analysis libraries, and client log repositories, as a possible implementation, the aforementioned supplementary retrieval can automatically route to the target data source based on the missing data type. For example, if no issues are found in the order table and payment transaction table, the client logs can be further queried to confirm whether the user triggered a payment request on the front end but encountered a network interruption. Furthermore, in addition to the quantity threshold not being met, the triggering conditions for supplementary retrieval actions can also include timeliness constraints. For example, automatic supplementary retrieval can be enabled only for negative conclusions within the last 24 hours, while negative conclusions for historical data can be manually reviewed to balance system load and verification accuracy.

[0100] In an optional implementation, the rule-based validation process for the query execution results further includes: determining whether a specific value exists based on the query response information; if a specific value exists, determining whether the specific value has corresponding source information in the query execution results; if the specific value does not have corresponding source information, triggering a retry and updating the query response information. In this way, by binding the specific value in the query response information to the source of the tool call return result for validation, numerical illusions can be effectively blocked without significant additional overhead from the language model, ensuring that the output results have a traceable data source and significantly enhancing the objectivity and credibility of the query response.

[0101] In one example, when the system outputs that the total amount of content consumption yesterday was 128,500 yuan, the rule validation module first uses regular expressions to extract the integer 128,500, which is greater than or equal to four digits, from the text. Then, it iterates through all the tool call records and their return messages executed in this round of dialogue to check whether the value comes directly from the database query result set or the data message returned by the business interface. If it is found that the amount cannot be located in any of the above original return results, it is immediately determined that it lacks source information. The system automatically injects a correction prompt and runs the round again, driving the large language model to recalculate and update the query response information based on real data.

[0102] Optionally, the specific numerical value is used as the anchor object for rule validation, typically represented by statistical numbers contained in the query response text. Optionally, the aforementioned specific numerical value can be various statistical figures directly stated by the large language model in the query response information, such as the number of new users yesterday, the monthly cumulative transaction amount, the order refund success rate percentage, or inventory balance—all quantitative data. Since large language models tend to fabricate seemingly reasonable numbers that are not actually supported by real database records when generating natural language text, the aforementioned rule validation process identifies these specific numerical values ​​and uses them as anchor objects for the next step of source tracing. In actual implementation, the methods for identifying the aforementioned specific numerical values ​​can include, but are not limited to, regular expression matching, numerical entity recognition and extraction, or numerical field detection based on grammatical structure; this application does not limit the specific identification methods.

[0103] Optionally, considering the diverse forms of statistical indicators in different business scenarios, the specific values ​​mentioned above can include not only Arabic numeral integers, but also floating-point numbers with decimal places, monetary values ​​with thousands separators, percentage values ​​presented as percentages, or summaries directly stated after simple calculations. To avoid misjudgments, length thresholds or digit thresholds can be set when identifying the specific values ​​mentioned above. For example, source verification can be initiated only for integers with four or more digits, while single-digit numbers that clearly belong to serial numbers or rating levels can be ignored. In this way, verification resources can be concentrated on large numbers that are most likely to generate illusion risks, and system processing overhead caused by over-verification can be reduced.

[0104] Optionally, the corresponding source information represents the original source of the specific value in the tool's returned results, to confirm that the value is supported by real data. Optionally, the aforementioned corresponding source information usually points to the original result data returned after each tool function in the current dialogue or query processing chain is called. For example, when the large language model previously called the database query execution tool to complete a database retrieval, the field values ​​in its returned result set constitute the aforementioned corresponding source information; similarly, when calling the code retrieval tool to search a code repository, the statistical row count in its returned matching fragments can also be considered a valid source. Furthermore, the aforementioned source information is not limited to the numerical values ​​being completely identical; it can also include equivalent forms after being converted to a preset format. For example, if the database returns the integer 12345 while the response information is expressed as 12,345 or 12.3 thousand, in this case, a normalized comparison can confirm that it has a corresponding source.

[0105] Optionally, considering that multiple tool calls may be involved in multi-turn dialogues, the tracing scope of the aforementioned source information can cover all tool return messages accumulated during the current query processing, rather than being limited to the output of the last call. If there are multiple specific values ​​in the query response information, it is necessary to check the source of each value in the tool return result one by one. For values ​​that cannot be directly located, the system can also use the rule engine to generate follow-up instructions before retrying the process, driving the large language model to clarify the specific calculation method or the table field on which the value is based, so as to provide traceable function call basis in the next generation.

[0106] Optionally, retry processing is used to drive the large language model to regenerate a query response with a data source when the source of the numerical value is lacking. Optionally, the retry processing does not simply repeat the previous dialogue, but rather injects pre-built correction prompts into the large language model, explicitly pointing out that the previously generated numerical value lacks original data support, requiring the model to re-perform statistical induction or logical deduction based on the obtained tool return results before outputting an updated query response. During this retry process, the system can retain the previously loaded knowledge hierarchy content and the trimmed tool subset, only correcting the context for the missing data source, thus avoiding repeated high-consumption stages such as intent routing, tool trimming, and knowledge loading. In this way, on the one hand, answer self-correction can be completed without the user's awareness, and on the other hand, the additional processing overhead caused by failed quality checks can be effectively controlled.

[0107] In an optional implementation, the rule validation process for the query execution results further includes: determining whether the query execution results meet the preset empty result condition and whether the number of times the database retrieval action is executed meets the single execution condition; if it is determined that the preset empty result condition and the single execution condition are met, the query conditions are adjusted and a retry process is triggered. This effectively avoids misjudgments of empty results due to deviations in single query conditions or omissions in data boundaries, significantly improving query robustness and answer completeness.

[0108] In one example, when a user queries the member transaction records of an account on a specified date, the large language model initially returns zero rows of data after performing a search on the member order data table. At this time, the quality verification module detects that the current query execution result meets the preset empty result condition, and the number of times the database retrieval action is executed is single, thus confirming that the trigger condition for empty result retry is met. It should be noted that the above preset empty result condition can be determined by judging whether the number of rows returned by the query is equal to zero, while the single execution condition can be judged by detecting whether the number of times the same type of retrieval action has been executed in this round of dialogue is one. Based on this, the system automatically adjusts the originally written precise timestamp condition to a range condition with each extended preset duration before and after, and calls the execution query tool again to perform the retrieval. Specifically, adjusting the query conditions may include: (1) widening the time point of precise matching to a time period including several hours before and after the time point; (2) adjusting the strict equality user identifier matching to fuzzy matching ignoring uppercase and lowercase letters or spaces; (3) removing some restrictive fields in unnecessary joint queries. Through the above retry process, the system successfully captured records that existed outside the original precise time window due to cross-time zone entry delays, thus returning accurate member purchase information to the user.

[0109] Optionally, a preset empty result condition is used to determine whether the query execution result is empty data, which can be set according to the number of returned rows or error code.

[0110] Optionally, the preset empty result condition can be a criterion used by the system to determine that the query execution result does not contain any data records that match the retrieval logic. In the above scenario, this condition aims to identify false empty results caused by deviations in query condition settings or data distribution characteristics, thereby triggering subsequent retry mechanisms in a timely manner to improve the completeness of the answer. Specifically, the preset empty result condition may include, but is not limited to: the number of data rows in the result set returned by the database is zero; data rows exist in the result set but key indicator fields are all null values; or the result set is marked as incomplete due to timeout or sharding anomalies. It should be noted that the above description of the judgment dimensions of the preset empty result condition is only one example, and this application does not intend to limit its judgment logic. In actual implementation, it can be adaptively adjusted according to the return protocol of the underlying database engine or the specific application situation. One purpose of this embodiment is that by introducing the joint judgment of the preset empty result condition and the single execution condition, on the one hand, a retry can be initiated when it is confirmed that the condition has not been corrected, and on the other hand, meaningless repeated execution of query requests that have undergone multiple rounds of condition adjustments can be avoided, thereby balancing query efficiency and result accuracy.

[0111] Optionally, the preset empty result condition can also be differentiated based on different database retrieval action types. Considering the significant differences in data distribution and storage specifications among data tables in different business domains, as a possible implementation, for order transaction data tables, the preset empty result condition can be configured to detect that the number of rows in the result set is zero and not due to permission blocking; for log data tables, this condition can be set to detect that the number of rows in the result set is zero and the query time window has not exceeded the original data retention period. Furthermore, to avoid false empty results due to sharding delays or master-slave replication lags in the underlying distributed database, the above-mentioned preset empty result condition can also additionally verify the status of the database instance currently hit by the query when determining that the returned result is empty. If the instance status is marked as synchronization delay, the determination of an empty result can be temporarily suspended, and the query can be automatically retried after a preset time, or the query can be directly routed to the master database to re-execute the retrieval. In other words, the preset empty result condition is not a static Boolean judgment, but a set of conditions that can be dynamically combined and flexibly expanded according to the characteristics of the data source, the type of query action, and the system operating status.

[0112] Optionally, the single-execution condition is used to limit the number of times a database retrieval action has been executed, and can be determined based on the call records in the dialogue context. Optionally, the single-execution condition aims to ensure that the retry mechanism only applies to the initial retrieval action before condition adjustments, thereby preventing the system from repeatedly entering an infinite loop after multiple rounds of condition corrections. This condition can be implemented by monitoring the number of times a specific database retrieval tool has been successfully called in the current dialogue session; when the number of calls is exactly one, it is determined that the single-execution condition is met. It should be noted that the aforementioned count of call counts can be flexibly limited according to actual business needs. For example, it can be limited to the cumulative number of retrieval actions targeting the same data table, the same business domain, or the same set of query parameters. If a user changes their query request multiple times in the same session, resulting in scattered retrieval actions, the request hash value or subtask identifier in the dialogue state can be further used to distinguish different query boundaries; this embodiment does not limit this. One objective of this embodiment is to effectively constrain the upper limit of the number of retries triggered by jointly verifying the single execution condition and the preset empty result condition, thereby excluding real empty results caused by the absence of data, and thus balancing the accuracy of the answer with the reasonable consumption of system computing resources.

[0113] Optionally, adjusting query conditions can be used to change retrieval constraints to expand the hit range when no results are found, including reconfiguring the time window or matching precision. Optionally, adjusting query conditions can include relaxing retrieval constraints to cover potential data boundary areas, or tightening irrelevant conditions to reduce interference. As one possible implementation, when a user queries transaction records at a specific time point but returns no results, the system can adjust the originally precisely matched single-day timestamp to a floating window that includes preset durations before and after, thereby capturing data offset due to time zone conversion or batch data entry delays. Further, adjusting query conditions can also include: adjusting user identifiers that match strictly equal matches to a fuzzy matching mode that is compatible with case differences or space variations; removing or weakening some unnecessary joint query conditions, such as equality restrictions for temporary status flags or experimental label fields. To avoid returning too much noisy data due to overly relaxed conditions, the above adjustment operations can follow a preset gradient strategy, i.e., only minimal condition expansion is performed in the first retry; if no results are still returned, the adjustment magnitude is gradually increased in the next retry until a preset upper limit is reached and then stopped. It should be understood that the above explanation regarding the adjustment direction is only an example. In actual scenarios, the narrowing conditions or the search path can also be selected based on the data distribution characteristics.

[0114] like Figure 3 The diagram shown is an overview of the system architecture. The overall system architecture consists of five core modules: intent routing, knowledge layered loading, dynamic tool pruning, quality verification, and parallel sub-agents. The architecture is divided into five layers: Access layer: Includes two entry points: POPO (chat tool name) robot (for product / operations / developers to query data) and customer service ticket platform (automatic diagnosis via HTTP API).

[0115] Agent core engine layer: includes intent router, knowledge router (supports progressive loading of L0->L1->L2 three layers), tool dynamic trimming module (reducing 35+ tools to 6), function calling module and quality verification gate.

[0116] Self-evolving knowledge management layer: includes offline learner (automatic learning table), GitLab code learner (Seed & Expand), negative feedback self-learning (correction -> alias), QA cache and vector retrieval (ChromaDB).

[0117] Data source layer: includes DDB online library, BI / Doris offline library, GitLab code repository and client logs.

[0118] Parallel computing layer: contains multiple Sub-Agents (up to 5 running in parallel).

[0119] The intent routing module, upon receiving a user query request, first extracts a list of possible table name candidates from the user message using a keyword matching algorithm (retrieve_tables_with_scores), providing this list as a recommendation signal to the Router. The Router then sends these signals, along with the user message, knowledge base index, and list of learned items, to the LLM. The LLM analyzes the data and outputs a decision result in JSON format, including the intent type, the matched table name (mentioned_table / matched_known_table), the suggested first action, and the reasoning.

[0120] The knowledge layer loading module maintains a three-layer knowledge structure. Layer L0 is a business domain summary index, storing a list of all business domains in the system and a QA cache directory; it is loaded with each user request, totaling approximately 200 tokens. Layer L1 loads only a summary of the data tables and brief descriptions of business terms within a specific business domain after the Router hits that domain; it totals approximately 500 tokens. Layer L2 is the complete DDL structure, which is actively retrieved on demand by the LLM using the `get_table_schema` tool when SQL needs to be written; it does not require preloading.

[0121] The tool dynamic pruning module maintains a mapping table from intents to toolsets. Once the Router determines the intent type, the module selects the necessary toolset corresponding to that intent type from the global tool list (more than 35 tools). For example, the complete toolset corresponding to the `query_data` intent includes 12 tools such as `execute_sql` (execute SQL query), `get_table_schema` (get table structure), `execute_bi_sql` (execute BI query), `generate_chart` (generate chart), `export_csv` (export CSV file), `convert_timestamp` (convert timestamp), and `parallel_query` (parallel query). Tool injection employs a two-stage strategy: the first round injects only about 5 core tools (approximately 700 tokens, covering about 80% of query requests), and subsequent rounds add tools such as chart generation and parallel querying as needed based on the dialogue context; when the intent is `explore_code`, code exploration tools such as `search_gitlab_code`, `read_gitlab_file`, and `learn_code` are injected.

[0122] like Figure 4 The diagram illustrates an intent-driven tool trimming process, showcasing the workflow of dynamic tool trimming. The system has 25 tools, requiring approximately 6,000 words per injection for full implementation. Through intent routing, the tools are trimmed into: data lookup (6 tools), follow-up questions (4 tools), table learning (7 tools), skill application (8 tools), and diagnostic work orders (7 tools). A two-stage injection strategy is employed: the first stage injects the minimum toolset (table lookup structure + query execution + time conversion, approximately 700 words); the second stage adds tools based on keyword triggers (trend chart -> generate chart, download -> export table, comparison -> parallel query, crash -> log diagnosis). Through intent trimming, resource consumption is reduced by approximately 75%, and fewer tools result in more precise LLM selection.

[0123] Quality Verification Module. This module includes three types of pure rule checkers: answer quality verification, digital illusion evidence verification, and diagnostic conclusion cross-validation. All of them are pure rule logic (without calling LLM), and are executed after the Agent generates the final answer and before returning it to the user, achieving answer quality verification with zero LLM cost.

[0124] like Figure 5The diagram illustrates a zero-cost quality verification process, showcasing three quality verification rules after the LLM output. Rule 1: Negative Conclusion Cross-Validation – Checks if the answer contains negative words (not received / does not exist / expired). If the number of tables consulted is >= 2, it passes; if only 1 table is consulted, a second check is performed. Rule 2: Digital Evidence Verification – Checks if the answer contains >= 4 digits and whether the numbers have a source in the tool's results. If no source is found, it's suspected of being fabricated. Rule 3: Empty Result Retry – Checks if the query returns 0 rows and was only performed once. If so, it's adjusted and retried. If any rule fails, a correction prompt is injected to retry the process (unnoticed by the user). If all rules pass, the result is returned to the user. Pure rule verification does not call the large model and has an execution time of approximately 0.1 milliseconds.

[0125] Sub-agent parallel module. When a user's question involves two or more independent data query tasks, the system starts sub-agents to execute them in parallel. Each sub-agent completes its sub-task independently, and the main agent then aggregates the results.

[0126] like Figure 6 The diagram illustrates an automated work order diagnostic process, showing the complete flow from work order submission to diagnostic report generation. After work order submission, the system receives work order information and user ID via HTTP API and initiates parallel evidence collection: user data (checking the block / ban table, user information table, and mobile phone binding table), order data (checking the order table, payment records, and balance table), and client logs (downloading log packages, filtering abnormal information, and extracting key lines). These three types of evidence are pooled into an evidence pool (user status, order records, and error logs) and then cross-validated (a negative conclusion requires at least two tables of evidence, and the figures must have a source). Upon successful verification, a diagnostic report is generated (including conclusion, evidence chain, and credibility). If verification fails, a correction prompt is injected, and the process restarts. The average diagnostic time is 118 seconds (manual investigation takes 10-30 minutes), with a success rate of 95%.

[0127] According to one embodiment of the present application, the data query apparatus may include: The response module is used to respond to user-input query requests and determine query intent information based on the query requests; The determination module is used to filter a subset of target tools from a preset toolset based on query intent information, and determine the knowledge loading decision corresponding to the subset of target tools. The query module is used to call the large language model to perform query processing based on the target tool subset and knowledge loading decision, and obtain the query execution results. The validation module is used to perform rule validation on the query execution results and output the query response information after the validation is successful.

[0128] In this way, by filtering the target tool subset based on query intent information and determining knowledge loading decisions, it helps to reduce the overhead of context token transmission and server-side computing load. Furthermore, the rule verification mechanism helps to reduce repeated interactions caused by inaccurate results, thereby improving the processing efficiency and accuracy of data queries and alleviating server-side resource consumption.

[0129] The specific details of each part of the above-mentioned device have been described in detail in the method section of the implementation plan. For any undisclosed details, please refer to the implementation plan of the method section, and therefore will not be repeated here.

[0130] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the exemplary embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0131] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0132] The following is a detailed reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing the electronic device described in the embodiments of this application. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 1201, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1202 or a program loaded from memory 1208 into random access memory (RAM) 1203. The RAM 1203 also stores various programs and data required for the operation of the electronic device. The processor 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0133] Typically, the following devices can be connected to I / O interface 1205: input devices 1206 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1207 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 1208 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1209. Communication device 1209 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0134] In particular, according to one embodiment of this application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, one embodiment of this application includes a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication device 1209, or installed from memory 1208, or installed from ROM 1202. When the computer program is executed by processor 1201, it performs the functions defined in the methods described above in various embodiments of this application.

[0135] Figure 7 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0136] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0137] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0138] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A data query method, characterized in that, include: In response to a user's query request, determine the query intent information based on the query request; Based on the query intent information, a subset of target tools is selected from a preset toolset, and a knowledge loading decision corresponding to the subset of target tools is determined. Based on the target tool subset and the knowledge loading decision, the large language model is invoked to perform query processing and obtain the query execution result. The query execution result is subjected to rule validation processing, and the query response information is output after the validation passes.

2. The method according to claim 1, characterized in that, The step of determining the query intent information based on the query request includes: Perform keyword matching processing on the query request to obtain a set of candidate data objects; The candidate data object set and the query request are input into the large language model to obtain the intent analysis results; Based on the intent analysis results, the query intent information is determined.

3. The method according to claim 1, characterized in that, The step of filtering a subset of target tools from a preset toolset based on the query intent information includes: Based on the query intent information, determine the tool association relationship corresponding to the query intent information; Based on the tool association relationships, a first tool subset is determined from the preset toolset; During the execution of the query processing, a second tool subset is determined from the preset toolset based on the context information of the returned results of the executed tool calls and the current dialog state; The first tool subset and the second tool subset are merged to obtain the target tool subset.

4. The method according to claim 1, characterized in that, The determination of the knowledge loading decision corresponding to the target tool subset includes: Load the first-level knowledge, and determine the business domain to which the query request belongs based on the first-level knowledge to obtain the business domain information; If the business domain to which the query request belongs is determined, the second-level knowledge corresponding to the business domain information is loaded. Based on the second-level knowledge, the large language model is invoked to obtain the third-level knowledge, and a database retrieval action is performed based on the third-level knowledge.

5. The method according to claim 4, characterized in that, The first level of knowledge includes a list of business domains and an index directory of recorded queries; The second level of knowledge includes a data table summary and a description of business terminology corresponding to the business domain information; The third-level knowledge includes a data definition language description corresponding to the database retrieval action.

6. The method according to claim 1, characterized in that, The step of invoking a large language model to perform query processing based on the target tool subset and the knowledge loading decision includes: Determine whether the query request contains multiple independent subquery tasks; If it is determined that the query request contains multiple independent sub-query tasks, the query request is split into multiple sub-query requests; Based on each of the sub-query requests, the sub-agents driven by the large language model are invoked to perform query processing in parallel, and sub-execution results corresponding to each of the sub-query requests are obtained; The query execution result is obtained by summing the results of each sub-execution.

7. The method according to claim 6, characterized in that, Before splitting the query request into multiple sub-query requests, the method further includes: Based on the semantic association information in the query request, the dependency relationships between each of the sub-query tasks are determined; Based on the aforementioned dependencies, the execution order information for each of the sub-query requests is determined.

8. The method according to claim 1 or 4, characterized in that, The rule validation process for the query execution result includes: Based on preset negative keywords, determine whether the query response information contains a negative conclusion; If the negative conclusion is found, determine whether the number of data objects involved in the database retrieval action meets a preset number threshold. If the quantity does not meet the preset quantity threshold, a supplementary database retrieval action is triggered, and the query response information is updated based on the execution result of the supplementary database retrieval action.

9. The method according to claim 1 or 4, characterized in that, The rule validation process for the query execution result further includes: Based on the query response information, determine whether a specific value exists; If the specific value is determined to exist, it is determined whether the specific value has corresponding source information in the query execution result; If it is determined that the specific value does not have the corresponding source information, a retry process is triggered and the query response information is updated.

10. The method according to claim 4, characterized in that, The rule validation process for the query execution result further includes: Determine whether the query execution result meets the preset empty result condition, and whether the number of times the database retrieval action is executed meets the single execution condition; If the preset empty result condition and the single execution condition are met, the query conditions are adjusted and a retry process is triggered.

Images