A table inference context routing method and system for a locally deployed language model

Abstract

The application discloses a table reasoning context routing method and system for a locally deployed language model, first acquires a natural language question and a table data source; then calls a global planning model, generates a read-only SQL plan according to the natural language question and the table data source; compiles the read-only SQL plan into a directed acyclic execution graph, each node in the execution graph records an operation type, declares an input, an output position and an output contract; according to a node dependency relationship of the execution graph, executes a node with determined parameters by a static executor; verifies the output of the executed node, if the verification is passed, stores the output of the node as the input of a downstream node; if the verification fails, records failure evidence, and enters a local repair or global re-planning process according to the failure evidence; when all nodes of the execution graph pass the verification, generates a final answer.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and natural language processing, specifically to a table-based reasoning context routing method and system for locally deployed language models. Background Technology

[0002] With the widespread application of Large Language Models (LLMs) in data analysis, report question answering, enterprise knowledge bases, and intelligent office scenarios, table reasoning has become one of the important directions for the practical application of language models. A typical table reasoning task flow involves the user posing a data query question in natural language, and the system needs to complete multiple steps, including column selection, condition filtering, table joins, aggregation statistics, sorting comparisons, numerical calculations, and final answer normalization. Real-world business tables typically originate from spreadsheets, web tables, database export files, or multi-source reports, containing complex headers, missing values, inconsistent unit and time formats, implicit column semantics, and relationships between multiple tables. These factors collectively increase the complexity and error probability of table reasoning.

[0003] Existing table reasoning techniques mainly fall into three categories.

[0004] The first type involves directly prompting the large language model to read the table and output the answer. This method serializes the table and inputs it along with the natural language question into the large language model, which then directly generates the final answer. The advantage of this type of method is its simplicity, requiring no intermediate steps. However, its disadvantage is that it easily delegates deterministic calculations such as filtering, aggregation, sorting, and arithmetic comparisons to the model, making the intermediate calculation process unverifiable. When the table is large or the question is complex, the model is prone to numerical calculation errors and logical drift, and the source of these errors is difficult to pinpoint.

[0005] The second category involves generating SQL query statements or program code from a large language model, which is then executed by an executor to return results. This type of method utilizes a database engine or DataFrame engine to execute the program, improving computational reliability. However, this method typically treats the generated SQL statements or program code as a whole; if execution fails, a complete regeneration of the SQL statement or program code is often required. It also struggles to distinguish between node-level local value matching errors and structure-level overall plan errors. Because specific error nodes cannot be located, repair costs are high, and local errors can easily trigger a rewriting of the entire plan, resulting in unnecessary waste of computational resources.

[0006] The third category comprises agent-based methods that implement table reasoning through a cycle of planning, execution, observation, and repair. This type of method breaks down the table reasoning task into several steps. The model generates operation instructions step by step, the executor executes the instructions and feeds the results back to the model, which then iteratively repairs the results based on observations. This type of method possesses a certain degree of error recovery capability and represents an improvement over the first two categories.

[0007] However, existing intelligent agent-based table reasoning methods still have the following technical shortcomings.

[0008] Existing intelligent agent solutions typically input the complete natural language question, the complete table context, and the accumulated execution history into the same large language model in each iteration. For large cloud-based models, this directly results in a significant increase in inference costs; the problem is even more pronounced for locally deployed large language models. Limited by memory capacity, context window length, inference throughput, and deployment costs, locally deployed models are more prone to issues such as context congestion, slow response, unstable inference, and even service unavailability when processing long tables and multi-round execution trajectories. With a large number of historical trajectories repeatedly input into the model, the model needs to simultaneously handle three types of tasks: high-level semantic planning, low-level deterministic computation, and error recovery, causing token consumption to quickly exceed the local model's capacity.

[0009] Existing intelligent agent solutions suffer from unclear error scope. Some errors in table-based reasoning only involve the current operation node, such as inconsistent surface forms of filter values, different date formats, case differences, or simple unit normalization. Repairing these errors only requires modifying the filter predicate or format conversion function of the current node, without affecting other nodes in the execution graph or the overall SQL structure. Other errors involve the overall plan, such as incorrect table selection, incorrect join keys, incorrect aggregation paths, or cross-node dependency errors. Repairing these errors requires changing the topology of the execution graph or the dependencies between nodes. Existing solutions do not differentiate between these two types of errors. If all errors are handled by the same model and allowed to modify the entire plan, it can easily lead to excessive replanning of small local errors, wasting computational resources. Conversely, if all errors are repaired locally, structural errors may be incorrectly localized, leading to repair failures and repeated loops.

[0010] In existing intelligent agent solutions, the same model simultaneously undertakes three functions: high-level semantic planning, low-level deterministic computation, and error recovery. These tasks vary significantly, and switching roles within the same context can easily lead to unstable output. Specifically, this manifests as follows: when generating the initial SQL plan, the model may produce column binding errors, filtering condition errors, or join key errors; when allowed to modify the complete SQL plan during the repair phase, there is a lack of boundary restrictions on the scope of modification. Repair actions may exceed the local scope of the erroneous node, modifying irrelevant nodes or disrupting dependencies in the execution graph, thus introducing new errors into the repair process. Existing solutions lack fine-grained control over repair permissions and fail to limit the scope of nodes and action types that the model can modify based on the error type.

[0011] In summary, existing technical solutions have not solved the following technical problems: how to accurately locate, determine the scope of, and fix different types of errors in the table reasoning process under the resource-constrained condition of deploying a large language model locally, while minimizing the number of language model calls and input token consumption. Summary of the Invention

[0012] To address the shortcomings of existing technologies, this invention proposes a table reasoning context routing method and system for locally deployed language models. This method divides the table reasoning process into stages such as global planning, execution graph compilation, static execution, result verification, error scope determination, local repair, and global replanning. By separating deterministic table computation from language model reasoning, establishing an error scope determination mechanism based on execution graph nodes, and implementing alternating calls between the local repair model and the global planning model, the language model intervenes only when semantic judgment or structural replanning is required. This significantly reduces token consumption and computational resource usage in locally deployed scenarios while maintaining the accuracy of table reasoning, and improves the controllability of error handling and the success rate of error repair.

[0013] To achieve the above objectives, the technical solution specifically adopted by the present invention is as follows: A table-based reasoning context routing method for locally deployed language models includes: Step 1: Obtain the natural language question and table data source; Step 2: Invoke the global planning model to generate a read-only SQL plan based on the natural language problem and the table data source; Step 3: Compile the read-only SQL plan into a directed acyclic execution graph, where each node in the execution graph records the operation type, declared input, output location, and output contract; Step 4: According to the node dependencies in the execution graph, the static executor executes the nodes whose parameters have been determined; Step 5: Verify the output of the completed node. If the verification passes, store the node output as the input of the downstream node. If the verification fails, record the failure evidence and proceed to the local repair or global replanning process based on the failure evidence. Step 6: When all nodes in the execution graph pass the verification, generate the final answer.

[0014] Preferably, the global planning model calls a locally deployed large language model.

[0015] Preferably, the compilation method of the execution graph is as follows: First, the obtained SQL plan is parsed to translate the SQL language into operator-level execution steps, then it is transformed into a directed acyclic graph, and the conditional statements in the language are used as the basis and node parameters of the directed acyclic graph. Finally, the content in the SQL statement is transformed into the dependency relationship between graphs to obtain the specific content of the execution graph.

[0016] Preferably, the operation types include scanning, filtering, joining, aggregation, sorting, projection, limiting, comparison, arithmetic calculation, and format conversion.

[0017] Preferably, the declared input is the input of prior information that a node needs to support it in completing its work when performing a task. Each node needs to declare the source of its dependent prior input data, including static input and dynamic output from other nodes.

[0018] Preferably, the output location is a location where the result content is saved after the node completes the task, so that subsequent nodes can accurately obtain this information through the information of the output location.

[0019] Preferably, the output contract involves checking whether the output content of each node meets the expected output format after the node has finished executing.

[0020] Preferably, in step 4, the static executor scans, filters, connects, sorts, aggregates, projects, and groups the execution nodes with determined parameters according to the operation type and execution parameters declared by the nodes, and generates the execution results of the corresponding nodes.

[0021] Preferably, in step 5, the content to be verified includes the output data type, column set, schema, result shape, non-null constraint, scalar constraint, and security constraint.

[0022] Preferably, the verification method includes verifying the output of the completed node and verifying that all nodes pass the verification. After node output verification: If no execution exception is thrown and the output passes the output contract verification after the node is executed by the static executor, the execution is considered successful; if the executor encounters a runtime exception or the node output fails the contract check, it will be considered an error; the system will determine whether it meets the requirements based on the type, schema, shape and required fields of the node's output contract check result and perform operator-specific checks. All nodes pass verification: Nodes are run in the topological order of the execution graph. Each node must complete its execution and pass the output verification. The algorithm is considered to have succeeded when it confirms that the states of all nodes in the execution graph are valid. All nodes pass, the final node output satisfies the contract, and the normalized answer is successfully returned, indicating that the answer is generated normally at the execution and structural levels.

[0023] Preferably, in step 5, if the verification fails, the system determines whether the error meets the closure condition based on the failure evidence. The closure condition includes: Evidence conditions, namely, that the cause of failure can be explained solely by the failing node and its declared input; Repair conditions, namely, the candidate repair actions only modify the failed node and do not change other nodes, do not change the dependencies between nodes, and do not change the connection structure and the overall SQL plan; Budget conditions, namely, keeping the input of the local repair model within the preset token limit; When all the closure conditions are met, the local repair model is invoked to repair the failed node; If any of the closing conditions is not met, the global planning model is invoked to generate a revised SQL plan.

[0024] Preferably, the local repair model receives failed nodes, declaration inputs, representative values, error information, and a list of allowed repair actions, but does not receive the complete execution history; the local repair model outputs structured repair candidates, and the representative values ​​include the first N samples of the failed node input dataset.

[0025] Preferably, the structured repair candidates include predicate repair and constraint function synthesis; Modify the predicates in the current file node through predicate repair; The constraint function is synthesized by determining the required data transformation type based on the execution failure node, declaring the function's input and output types, limiting the data range that the function can access and the basic operations that are allowed to be called, calling the local repair model to generate a function expression that satisfies the input and output constraints, and using a static executor to verify the function's return value type, output format, and execution result; after successful verification, the function is applied to the current execution node, the data transformation type is automatically inferred based on the mismatch between the output contract and the input type, and the data range is limited to the current node's input column and its derived columns.

[0026] Preferably, the global planning model receives the natural language question, the current SQL plan, failed nodes, relevant intermediate results, alternative columns, node dependencies, and evidence of previous local repair attempts, and generates a revised SQL plan; the revised SQL plan undergoes read-only checks, available table column checks, and compilation checks before execution.

[0027] This invention also discloses a table-based reasoning context routing system for locally deployed language models, comprising: The input management module is used to receive natural language questions and at least one tabular data source, extract table names, column names, data types, sample values ​​and candidate key relationships, and generate a table summary; A global planning module is used to generate a read-only SQL plan or revise the SQL plan based on the natural language problem and the table summary. The SQL compilation module is used to compile the read-only SQL plan into an execution graph; The static execution module is used to perform deterministic table operations according to the node dependencies of the execution graph; The output validation module is used to validate the node output, checking whether the output meets one or more of the following criteria: data type, table mode, column set, result shape, non-null requirement, scalar requirement, and security constraint. The failure evidence collection module is used to record failure evidence when node verification fails; The context routing module is used to determine whether the closure condition is met based on the failure evidence, preset token restrictions, and allowed repair actions, and decide whether to enter local repair or global replanning accordingly. The local repair module is used to receive node-level evidence and a list of allowed actions, and generate structured repair candidates when the closure condition is met. The global replanning module is used to receive the current SQL plan and selective global evidence when the closure condition is not met, and modify column bindings, join keys, aggregation paths or SQL structures to generate a revised SQL plan; The results output module is used to normalize the verified execution graph results and output the final answer.

[0028] Preferably, the local repair module and the global planning module are implemented using the same basic locally deployed language model, but with different prompt templates, different context scopes, and different action permissions.

[0029] Preferably, a termination control module is also included, which is used to terminate when all nodes of the execution graph pass verification and generate the final answer; and to terminate when the local repair limit is reached, the global replanning limit is reached, a duplicate SQL plan is detected, or an unchanged failure is detected.

[0030] Separating deterministic table computation from language model inference reduces numerical errors and logical drift caused by intermediate computation results generated by the model; by constraining the scope of evidence and modification for local repair through observable closure conditions, the local model only processes node-level errors, avoiding unnecessary rewriting of the overall SQL plan; by calling the global planning model only in structural error scenarios and providing selective evidence, the repeated input of complete context, complete tables, and complete historical trajectories is reduced, thereby improving token efficiency; it is suitable for local deployment of language models and can complete table inference without relying on large cloud models to process complete data, which is beneficial for privacy protection, deployment cost control, and system reproducibility. Attached Figure Description

[0031] Figure 1 This is a diagram of the overall architecture of the context-routing table reasoning of the present invention.

[0032] Figure 2 This is a flowchart illustrating the error scope determination and local / global alternation process of the present invention.

[0033] Figure 3 This is a schematic diagram of an embodiment of the present invention in a single-table scenario.

[0034] Figure 4 This is a schematic diagram of an embodiment of the present invention in a multi-table scenario. Detailed Implementation

[0035] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0036] Example 1:

[0037] A table-based reasoning context routing method for locally deployed language models, such as Figure 1 As shown, it includes the following steps: Step 1: Obtain the natural language question and table data source; Specifically, after the system starts, the input management module first receives a natural language question Q submitted by the user and at least one tabular data source T.

[0038] The data source for the tables can originate from spreadsheet files, web-based tables, database query results, CSV files, or structured data returned by application programming interfaces (APIs). When multiple tables are involved, they can be stored in the same data source or come from different data sources. The tables can have potential relationships with each other or be independent of each other.

[0039] The input management module performs preprocessing operations on the received tabular data sources. For each input table, the module extracts the table name, column name of each column, data type of each column, sample value of each column, and candidate primary key or foreign key relationships between different columns. Candidate primary keys are columns or combinations of columns that have unique and non-null values; foreign key relationships are identified through column name similarity matching or value overlap analysis between columns of different tables.

[0040] The input management module generates a table summary for use by the global planning model based on the extracted information. The table summary adopts a structured text format, organized by tables, with each table listing the column names, data types, and several sample values ​​for all columns. For discrete columns with a limited number of values, the table summary may also include information on all different values ​​or the distribution of the main values ​​for that column.

[0041] Step 2: Invoke the global planning model to generate a read-only SQL plan based on the natural language problem and the table data source.

[0042] In this embodiment, the global planning module calls a locally deployed large language model as the global planning model. The global planning model is a locally deployed pre-trained language model, which can be a general open-source large language model or a specialized model that has been fine-tuned on a table reasoning task.

[0043] The global planning module uses a preset prompt template to guide the global planning model in generating an SQL plan. The prompt template includes the following components: First, system role setting. System role setting is used to inform the model of its identity and behavioral boundaries in the current task. For example, it instructs the model to act only as a data analysis expert, responsible for converting natural language questions into read-only SQL query statements.

[0044] Second, table summary information. The table summary generated by the input management module is embedded in the prompt template in the form of structured text, so that the model knows the available table names, column names, column types, and sample data.

[0045] Third, user natural language questions. Embed the user's original question into the prompt template.

[0046] Fourth, output format constraints. Output format constraints are used to limit the model to return only the SQL statement itself, without returning any additional explanatory text or other irrelevant content.

[0047] Based on the aforementioned prompt template, the global planning model generates a read-only SQL plan corresponding to the natural language question and the tabular data source. The read-only SQL plan describes the data source to be queried, target columns, filter conditions, join relationships, aggregation methods, sorting methods, and output fields.

[0048] The global planning module performs a read-only check on the SQL plan output by the model. This read-only check is implemented through regular expression matching or the SQL syntax parser. The read-only check includes: ensuring that the SQL statement begins with the SELECT keyword; confirming that it does not contain data modification or permission change keywords such as INSERT, UPDATE, DELETE, DROP, ALTER, CREATE, GRANT, and REVOKE; confirming that it does not contain file write operations such as INTO OUTFILE and INTO DUMPFILE; confirming that it does not contain system stored procedure calls; and confirming that all table names in the FROM clause exist in the table summary generated by the input management module.

[0049] If the read-only check fails, the system rejects the SQL plan and returns an error message, instructing the global planning model to regenerate an SQL plan that meets the read-only requirements.

[0050] Step 3: Compile the read-only SQL plan into a directed acyclic execution graph, where each node in the execution graph records the operation type, declared input, output location, and output contract.

[0051] Specifically, the SQL compilation module compiles the SQL plan, which has undergone read-only checks, into a directed acyclic execution graph G=(V,E), where V is the set of nodes and E is the set of directed dependency edges between nodes.

[0052] The specific implementation method of the compilation process is as follows: First, the SQL compilation module uses an SQL syntax parser to perform lexical and syntactic analysis on the read-only SQL plan, generating an abstract syntax tree. The SQL syntax parser can be implemented using an open-source SQL parsing library or a self-developed recursive descent parser.

[0053] Secondly, the SQL compilation module traverses the abstract syntax tree, translating the SQL language into operator-level execution steps. Each clause or logical unit in an SQL statement corresponds to one or more execution operators. Specifically, the column expression in the SELECT clause corresponds to the projection operator, the table name in the FROM clause corresponds to the scan operator, the JOIN clause corresponds to the join operator, the WHERE clause corresponds to the filter operator, the GROUP BY clause corresponds to the aggregation operator, the ORDER BY clause corresponds to the sorting operator, the LIMIT clause corresponds to the restriction operator, the HAVING clause corresponds to the post-filter operator, and the arithmetic expressions, comparison expressions, and type conversions in the SELECT clause correspond to the computation operators.

[0054] Then, the SQL compilation module determines the order of execution operators based on data flow dependencies, encapsulating each operator as a node in the execution graph, with the data flow direction between operators corresponding to the directed edges between nodes. For example, filtering operators must be executed after scanning operators because filtering requires the scan results as input; aggregation operators must be executed after filtering operators because aggregation requires the filtered data; and sorting operators must be executed after aggregation operators because sorting requires the aggregation results.

[0055] Finally, the SQL compilation module records the constant values, column names, and table names in the abstract syntax tree as execution parameters in the corresponding nodes. At the same time, it derives the expected output pattern for each node based on the target output form of the SQL statement, which serves as the output contract for that node.

[0056] In the execution graph generated by the above compilation process, each node records the following information: The operation type indicates the specific table operation performed by the node. In this invention, the operation types include, but are not limited to, scanning, filtering, joining, aggregation, sorting, projection, limiting, comparison, arithmetic calculation, and format conversion.

[0057] The following operations are available: Scan operation: reads all rows of data from a specified column in the input table data source; Filter operation: filters the input row set based on predicate conditions, keeping only rows that meet the conditions; Join operation: performs inner join, left join, or full join on two input datasets based on the join key; Aggregate operation: groups by grouping key and performs aggregation calculations such as summation, counting, average, maximum, and minimum on each group; Sort operation: sorts the input dataset by a specified column and sorting direction; Projection operation: selects a specified subset of columns or calculates a new derived column; Limit operation: extracts the first K rows of the input dataset; Comparison operation: performs comparison operations such as size and equality on two values ​​or two columns; Arithmetic operation: performs addition, subtraction, multiplication, division, modulo, and exponentiation on numerical columns; Format conversion operation: performs unified format conversion on strings, dates, and numbers, such as case standardization, date format unification, and whitespace removal.

[0058] Each node requires one or more pre-processing inputs to support its task execution. The declared inputs are the pre-processing input data sources that the node depends on. Each node must declare its pre-processing input data sources, including static inputs and dynamic outputs from other nodes.

[0059] Static input refers to constant parameters that are determined before execution, such as constant values ​​in filtering conditions, sorting direction indicators, and row limit limits. Dynamic output from other nodes refers to the output data generated after the direct upstream node of this node has completed execution. This output data is stored in a specific location and can be retrieved by the current node by referencing the output location of the upstream node.

[0060] For starting nodes in the execution graph, such as scan nodes, their declaration inputs can be empty or contain only static parameters. For non-starting nodes, their declaration inputs must explicitly list the identifiers of all directly upstream nodes and their corresponding output location references.

[0061] The output location refers to the storage location of the results of a node after it has completed its task. After each node finishes execution, its output is stored in a specific storage area, and subsequent nodes can accurately retrieve this information using the information in the output location.

[0062] Output locations can be implemented using various methods such as memory addresses, variable names, temporary table identifiers, or cache keys, as long as the identifier is unique within the execution graph and addressable by downstream nodes. Output locations are pre-allocated during node compilation and the actual data is written after the node execution is complete.

[0063] The output contract is used to check whether the output of each node meets the expected output format after execution. The output contract is the data format specification that the node's output should meet, and it is used in subsequent verification processes.

[0064] The output contract includes, but is not limited to: the expected data type of each column in the output result, the expected set of column names and column order, the result shape information including the expected range of rows and columns, non-null constraints indicating which columns are not allowed to be null or empty results, scalar value constraints such as numerical range, string length limit, enumeration value set, etc., and security constraints such as prohibiting the output of content containing specific sensitive data patterns.

[0065] In addition to the four types of information mentioned above, each node in the execution graph also records its execution status and retry count. The execution status includes values ​​such as pending execution, executing, successful execution, failed execution, and skipped. The retry count records the number of times the node has attempted to repair or re-execute, and is used for subsequent termination condition determination.

[0066] After the SQL compilation module generates the execution graph, the execution graph management module saves the node dependencies, node status, node execution results, and node repair records of the execution graph for use in subsequent execution and verification stages.

[0067] Step 4: According to the node dependencies in the execution graph, the static executor executes the nodes whose parameters have been determined.

[0068] Specifically, the static execution module executes the deterministic nodes in the execution graph according to the topological order of the graph. The topological order refers to the execution order determined by the directed dependency edges between nodes, ensuring that all upstream dependent nodes of each node have been executed and verified before execution.

[0069] The static executor performs corresponding table operations on execution nodes with defined parameters based on the operation type and execution parameters declared by the nodes, and generates the execution results for the corresponding nodes. Specifically, the static executor performs deterministic table operations such as scanning, filtering, joining, sorting, aggregation, projection, and grouping statistics on execution nodes with defined parameters.

[0070] The term "node with determined parameters" refers to a node whose declared inputs are all ready. For starting nodes, such as scan nodes, their parameters are determined at compile time; for non-starting nodes, the input parameters of the node are determined after all its upstream nodes have completed execution and the output verification has passed, and it can be executed by the static executor.

[0071] Static executors do not invoke the language model when executing business logic, thus avoiding additional model input and output token costs. Static executors can be implemented using various execution engines, including but not limited to: embedded SQL execution engines, DataFrame execution engines, custom implementations of relational algebra executors, or streaming execution engines. Regardless of the execution engine used, static executors provide a unified input / output interface, accepting node declarations and parameters, performing deterministic computation, and returning the node output dataset.

[0072] The execution process of the static executor includes the following steps: First, locate and read the output data of all upstream nodes according to the node's declaration input; second, perform corresponding table operations on the input data according to the node's operation type and parameters; then, write the execution result to the node's pre-assigned output location; finally, mark the node status as "execution completed" and notify the output verification module to perform verification.

[0073] Step 5: Verify the output of the completed node. If the verification passes, store the node output as the input of the downstream node. If the verification fails, record the failure evidence and proceed to the local repair or global replanning process based on the failure evidence.

[0074] Specifically, such as Figure 2 As shown, the output verification module verifies the output of each node after the static executor has completed execution. The verification content includes one or more of the following: output data type, column set, schema, result shape, NOT NULL constraint, scalar constraint, and safety constraint.

[0075] Data type validation checks whether the actual data type of each column in the output results is consistent with the type declared in the output contract. For example, if the contract declares a column as a floating-point number, the actual output should be numeric data, and cannot be a string or a null value.

[0076] The column set validation checks whether the output contains all the columns required by the contract and does not include any unexpected columns. Column name matching can be done in a case-insensitive manner.

[0077] Schema validation checks the overall schema of the output results, including whether the column names, column order, and column type combinations completely match the contract.

[0078] The shape validation check ensures that the number of rows and columns in the output are within the range specified in the contract. For example, an aggregation node is expected to output a single row when there is no grouping key; returning an empty row or more than one row is considered an anomaly.

[0079] The NOT NULL constraint validation checks whether columns or result sets marked as NOT NULL in the contract contain null values ​​or are empty results. If null values ​​or empty results are found, a repair process may be triggered depending on the context.

[0080] Scalar constraint validation checks whether the results of aggregate calculations are within a reasonable numerical range, such as non-negative amounts or percentages between zero and one hundred. Scalar constraints can be preset in the system configuration or dynamically calculated from column statistics.

[0081] The security constraint verification check outputs whether there is a risk of sensitive data leakage. This verification is especially critical in enterprise local deployment scenarios.

[0082] The verification method includes two levels: verification of the completed node output and verification of all nodes passing the verification.

[0083] The specific determination method for node output verification is as follows: If no execution exception is thrown after the node is executed by the static executor, and the output passes the output contract verification, the execution is considered successful. If the executor encounters a runtime exception, or the node output fails the contract check, it will be considered an error. The system will determine whether the requirements are met based on the type, mode, shape, and required fields of the node's output contract check results, and will perform operator-specific checks. Operator-specific checks refer to special verifications added according to different operation types, such as checking the non-nullability of aggregation results for aggregation operators, and checking for duplicate row exceptions in the join results for join operators.

[0084] The specific method for determining whether all nodes pass verification is as follows: the system runs the nodes according to the topological order of the execution graph. Each node must complete its execution and pass the output verification. When the algorithm confirms that the states of all nodes in the execution graph are valid, it is considered to have succeeded. If all nodes pass, the final node output satisfies the contract, and a normalized answer is successfully returned, it indicates that the answer was generated normally at the execution and structural levels.

[0085] When the verification is successful, the output verification module stores the node's output in the storage area indicated by its output location as input data for downstream nodes, marks the node's status as "execution successful", and notifies the execution graph management module to update the node status.

[0086] When verification fails, the error information collection module records the failure evidence. The failure evidence includes the following: the failure node identifier and operation type; a summary of the failure node's declared inputs, including the number of input rows, input column names, input column types, and sample values ​​from the first few rows; the names of the referenced columns involved in the failure node's operation and their representative values; the error type and error message captured by the system; the node's output contract; the node's actual output result if the executor returned partial results; the identifiers, operation types, and output status summaries of all upstream dependent nodes of the failure node; a list of previously attempted repair actions for the node and the results of each repair; and a local dependency subgraph centered on the failure node.

[0087] After recording the failure evidence, the context routing module determines whether the error meets the closure condition based on the failure evidence, and decides whether to enter the local repair process or the global replanning process based on the judgment result.

[0088] The closure conditions include three aspects: evidence conditions, restoration conditions, and budget conditions.

[0089] The evidentiary condition refers to the reason for failure being explainable solely by the failing node and its declared inputs. Specifically, the context routing module checks the set of input data sources for the failing node. If all input data for the failing node originates directly from its immediate upstream node, and the error message does not reference outputs from more distant nodes or global SQL semantics, then the evidentiary condition is met. If the error message indicates a need to modify the join key, table selection, or cross-node data flow, then the evidentiary condition is not met.

[0090] The repair criteria refer to the fact that candidate repair actions only modify the failed node without changing other nodes, the dependencies between nodes, the connection structure, or the overall SQL plan. Specifically, the determination method is as follows: the context routing module maintains a dynamically determined "set of allowed repair actions" based on the node operation type. Allowed repair actions for filtering nodes include modifying predicate conditions, adding or deleting predicate terms, and modifying comparison operators; allowed repair actions for format conversion nodes include modifying the target format mode and adding conversion functions. If possible repair solutions exceed the range of this set, the repair criteria are not met.

[0091] The budget condition requires that the input to the local repair model remain within a preset token limit. This token limit is a system-preset configurable parameter, with a default value of 80% of the model context window size. The context routing module estimates the total number of tokens for the local repair model input, including tokens for system prompt templates, failed node information, input summary declarations, representative values, error messages, and the list of allowed repair actions. If the estimated total number of tokens does not exceed the preset limit, the budget condition is met.

[0092] When all the evidence conditions, repair conditions, and budget conditions are met, the context routing module calls the local repair model to repair the failed node and proceeds to the local repair sub-process in step 5.

[0093] When any of the evidence conditions, repair conditions, and budget conditions is not met, the context routing module calls the global planning model to generate a revised SQL plan and enters the global replanning subprocess in step 5.

[0094] The local repair model receives failed nodes, declaration input, representative values, error messages, and a list of allowed repair actions, but does not receive the complete execution history. The representative values ​​include the first N samples from the failed node input dataset, where N is a system preset value, defaulting to five samples.

[0095] The input prompt template of the local repair model explicitly constrains its output format, requiring the output to be structured repair candidates rather than open-ended natural language interpretations. These structured repair candidates include two types: predicate repair and constraint function synthesis.

[0096] Predicate repair is used to modify the predicates in the currently failed node. Specific methods of predicate repair include: modifying the comparison operator (in this embodiment, "equal to" is changed to "included in"); expanding a single comparison value into a set of multiple possible values; adding value conversions, such as unifying both sides of the comparison to the same format; and adjusting boundary values, such as adjusting the upper or lower bound of the date range by one day to include the boundary date. Before performing predicate repair, the system verifies whether the modified predicate references a valid column name, whether the comparison value type matches the column type, and whether it is a read-only operation.

[0097] The constraint function synthesis process determines the required data transformation type based on the execution failure node, declares the function input and output types, limits the data range that the function can access and the basic operations that are allowed to be called, calls the local repair model to generate a function expression that satisfies the input and output constraints, uses a static executor to verify the function return value type, output format and execution result, and applies the function to the current execution node after verification.

[0098] The specific process of constraint function synthesis is as follows: First, based on the mismatch between the output contract and input type of the failed node, the required data conversion type is automatically inferred. In this embodiment, if the input is a string type but the output contract requires a date type, a date format conversion function is inferred; if the input contains mixed case but the output contract requires uniform case, a case normalization function is inferred. Second, the constraint function declares its input type, output type, and the number and order of input parameters. Then, the data range that the function can access is limited to the input columns of the current node and their derived columns. The function can only reference columns declared in the node's input and cannot reference outputs from other nodes or global variables. Simultaneously, the set of basic operations that the function is allowed to call is limited, including a whitelist of string operations, date operations, numeric operations, and logical operations. Then, the local repair model is called to generate a function expression that meets the input and output requirements under the above constraints. The model output is a pure function definition without explanatory text. Afterward, the generated function is executed on limited test data using a static executor to verify whether the return value type is consistent with the declaration, whether the output format meets the output contract requirements, whether the function can execute normally for all representative input values, and whether the execution time does not exceed a preset threshold. After successful verification, the synthesized function is applied to the input data of the current execution node to generate the transformed output, which is then handed over to the static executor to re-execute the node.

[0099] If the structured repair candidate output by the local repair model passes the format check, scope check, and security check, the system will apply the repair to the failed node, reset the state of the node and all its downstream nodes to pending execution, clear the old output, and then return to step 4 to re-execute the relevant nodes.

[0100] If the local repair verification fails or the number of local repair attempts reaches the preset limit, the system will be upgraded to a global replanning process.

[0101] The global planning model receives the natural language question, the current SQL plan, failed nodes, relevant intermediate results, alternative columns, node dependencies, and evidence of previous local repair attempts, and generates a revised SQL plan.

[0102] The input prompt template for the global planning model adds the following content to the initial planning template: a summary of the execution status of the current SQL plan, failure nodes and their error messages, and guiding constraints to guide the model to avoid the above errors when replanning the SQL plan. You can modify column bindings, join keys, aggregation paths, or SQL structures, but you must keep them read-only.

[0103] The revised SQL plan undergoes read-only checks, available table column checks, and compilation checks before execution.

[0104] The read-only check is performed in the same way as in step 2, ensuring that the revision plan remains a read-only query.

[0105] The table column check can be used to confirm that all table names and column names referenced in the revision plan exist in the input table summary; if a table or column is referenced that does not exist, the plan is rejected.

[0106] The compilation check sends the revision plan to the SQL compilation module to verify that it can be successfully compiled into a valid execution graph. If the compilation fails, the plan is rejected.

[0107] After all three checks pass, the system accepts the revised SQL plan, uses it as the new execution plan, clears the old execution graph, rebuilds the execution graph, and starts execution from step 3.

[0108] Global replanning is also subject to a maximum number of attempts. If the number of global replanning attempts reaches the preset limit, or the system detects that the revised plan is exactly the same as the plan in a previous round, or the system detects that the failed nodes and error messages have not changed after re-execution, the execution process will be terminated.

[0109] Step 6: When all nodes in the execution graph pass the verification, generate the final answer.

[0110] Specifically, when all nodes in the execution graph have completed execution and passed output verification, the termination control module determines that the execution was successful.

[0111] The output module will normalize the output of the final node in the execution graph and generate the final answer to return to the user.

[0112] Normalization includes one or more of the following operations: converting tabular results into natural language answer format; standardizing numerical output format, such as retaining a specified number of decimal places, adding thousands separators, and standardizing currency symbols; standardizing date output format; handling null values, such as replacing them with "no data" or specifying a default value; and appropriately truncating or summarizing multi-row results.

[0113] If the system terminates due to reaching the limit for local repair attempts, the limit for global replanning attempts, detecting duplicate SQL plans, or detecting failures due to no changes, the result output module returns a preset error message and may include some intermediate results of successful execution for reference.

[0114] Example 2:

[0115] This embodiment provides a table-based reasoning context routing system for locally deployed language models, including: The input management module is used to receive natural language questions and at least one tabular data source, extract table names, column names, data types, sample values ​​and candidate key relationships, and generate a table summary; A global planning module is used to generate a read-only SQL plan or revise the SQL plan based on the natural language problem and the table summary. The SQL compilation module is used to compile the read-only SQL plan into an execution graph; The static execution module is used to perform deterministic table operations according to the node dependencies of the execution graph; The output validation module is used to validate the node output, checking whether the output meets one or more of the following criteria: data type, table mode, column set, result shape, non-null requirement, scalar requirement, and security constraint. The failure evidence collection module is used to record failure evidence when node verification fails; The context routing module is used to determine whether the closure condition is met based on the failure evidence, preset token restrictions, and allowed repair actions, and decide whether to enter local repair or global replanning accordingly. The local repair module is used to receive node-level evidence and a list of allowed actions, and generate structured repair candidates when the closure condition is met. The global replanning module is used to receive the current SQL plan and selective global evidence when the closure condition is not met, and modify column bindings, join keys, aggregation paths or SQL structures to generate a revised SQL plan; The results output module is used to normalize the verified execution graph results and output the final answer.

[0116] The local repair module and the global planning module are implemented using the same basic locally deployed language model, but with different prompt templates, different context scopes, and different action permissions.

[0117] It also includes a termination control module, which terminates when all nodes in the execution graph pass verification and generate the final answer; and terminates when the local repair limit is reached, the global replanning limit is reached, a duplicate SQL plan is detected, or an unchanged failure is detected.

[0118] Example 3: For local repair of inconsistent filter value formats in a single table, this embodiment combines... Figure 3 The single-table scenario shown illustrates the local repair process of this invention in the case of inconsistent filter value formats in a single table.

[0119] In a business sales report analysis scenario, a user submits a natural language question to the system: "What was the highest-selling product in North America in 2023?" The system receives a single table, "Sales Report," which contains columns for "Year," "Region," "Product," and "Sales Amount." However, the actual values ​​in the "Region" column are inconsistent. For example, the North American region is represented by both "NA" and "North-America" ​​in the table, while the user's question uses the more natural language expression "North American region."

[0120] The initial read-only SQL plan generated by the global planning model based on the user's question contains the filter condition "region='North America'".

[0121] The system compiles the SQL plan into an execution graph, which includes at least scan nodes, filter nodes, aggregation nodes, and projection nodes. The scan node reads all data rows from the input table. The filter node's declarative input is the output of the scan node, with the filter condition "Year=2023 AND Region='North America'". The aggregation node's declarative input is the output of the filter node, grouping by "Product" and calculating the sum of "Sales". The projection node selects the final output columns.

[0122] The node scan was successful, and all table data was output.

[0123] When the filter node is executed, since the actual values ​​of the "Region" column in the table are "NA" and "North-America", and there is no exact value for "North America", the filter result is an empty set. The filter node does not meet the non-empty requirement in the output contract, and the verification fails.

[0124] The error information collection module records failure evidence, including: the failed node is a filter node with the filter parameter "Year=2023 AND Region='North America'", the input summary is all the data output by the scan node, the referenced column is the "Region" column and its representative values, the error message is that the filter result is empty, and the output contract is that the number of rows is greater than or equal to zero but the downstream expectation is not empty.

[0125] The context routing module determines whether the error meets the closure condition: Regarding the evidentiary conditions, the reason for the failure is that the value in the "Region" column does not match the value "NorthAmerica" ​​used in the filter predicate. This reason can be explained solely by the failing node and its declared input, without referencing other nodes or global SQL semantics. The evidentiary conditions are met.

[0126] Regarding the repair conditions, fixing this error only requires modifying the predicate conditions of the filter node, such as expanding a single value into a set of multiple possible values. Other nodes, inter-node dependencies, the join structure, and the overall SQL plan must not be modified. The repair conditions are met.

[0127] Regarding budget conditions, the input to the partial repair model only includes failed nodes, a summary of declared inputs, representative values ​​of referenced columns, error messages, and a list of allowed repair actions. It does not include complete table data and the complete execution history, and the estimated number of tokens is less than the preset token limit. The budget conditions are met.

[0128] If all three conditions are met, the context routing module will route the error to the local repair module.

[0129] The local repair model accepts node-level evidence but does not accept complete execution history, complete table data, or the output of other nodes. The structured repair candidates output by the local repair model will have their filtering predicate modified to "region contained in ('NA', 'North-America')".

[0130] After the system verifies that the repair candidate passes the format check, scope check, and security check, the modification will be applied to the filter node, and the status of the filter node and its downstream nodes will be reset to "pending execution".

[0131] The system re-executes the filter node. The new filter conditions successfully match all rows in the "Region" column of the table that have the value "NA" or "North-America". The filter node outputs a non-empty result, and the verification passes. The aggregation node and projection node continue to execute using the original dependencies, and finally output the correct answer.

[0132] In this embodiment, the system only invokes the local repair model when an error occurs at a filtering node. The repair scope is strictly limited to a single filtering node, and downstream aggregation and projection nodes do not require modification. The input token consumption of the local repair model is far lower than that of global replanning, and the repair process is completed locally without uploading data to the cloud.

[0133] Example 4: For global replanning of multi-table join structure errors, this embodiment combines... Figure 4 The multi-table scenario shown illustrates the global replanning process of this invention in the case of errors in the multi-table join structure.

[0134] In an e-commerce business analytics scenario, a user submits a natural language question: "Analyze the product categories with the highest return rates among various suppliers." The system receives three tables as data sources: an order table, a product table, and a return table. The order table contains columns for order identifier, product identifier, and supplier. The product table contains columns for product identifier and product category. The return table contains columns for order identifier and return status. This problem requires cross-table joins and aggregation calculations.

[0135] The global planning model generates an initial read-only SQL plan based on the user's problem. The SQL compilation module compiles the three tables into scan nodes and cross-table relationships into join nodes.

[0136] If the initial plan incorrectly uses product identifiers to connect the order table and the return table, when the return table should actually be connected to the order table via the order identifier, the connection node may produce empty results, duplicate row exceptions, or output patterns that do not conform to the expectations of downstream aggregation nodes.

[0137] The relevant scan node executed successfully. The connection node, executed based on an incorrect connection key, outputs an empty result or a duplicate row exception. The output verification module determines that the connection node verification failed.

[0138] The error information collection module records evidence of failure. The context routing module then determines the nature of the failure. This error does not meet the repair condition in the closure condition because repairing it requires changing the join key or cross-table dependencies. The scope of modification is no longer limited to value matching or format conversion of a single node, but involves the structural relationships between multiple tables. If the local repair model directly modifies the join relationships, it may cause it to cross node boundaries and break execution graph dependencies.

[0139] Therefore, the system escalates the error to a global replanning model.

[0140] The global replanning model receives the current SQL plan, failed connection nodes, column summaries of the three tables, connection node output exceptions, downstream aggregation requirements, and necessary intermediate result summaries.

[0141] The global model reselects the join key, connects the order table and the return table using the order identifier, connects the order table and the product table using the product identifier, and regenerates the SQL plan required for aggregating the return rate.

[0142] The revised SQL plan undergoes read-only checks, available table column checks, and compilation checks in sequence. Once verification is successful, the system rebuilds the execution graph and executes from the revised plan.

[0143] This embodiment demonstrates the division of labor between the local and global models in this invention: node-level errors are handled by the local repair module, while cross-table structural errors are handled by the global replanning module. This avoids the application of inappropriate local repairs to structural errors and improves the accuracy and controllability of multi-table reasoning.

[0144] Example 5: This embodiment provides token efficiency control under enterprise local deployment. In enterprise internal reporting and Q&A scenarios, tables may contain financial, operational, or customer data, which are not suitable for uploading to cloud models. The system deploys a medium-sized language model on a local server and configures this model as a global planning model and a local repair model.

[0145] The global planning model and the local repair model are implemented using the same underlying locally deployed language model, but with different prompt templates, different context scopes, and different action permissions. In global planning mode, the model receives the complete issue, table summary, and selective global evidence, and is allowed to modify the SQL structure. In local repair mode, the model only receives node-level evidence and is strictly limited to modifying only the currently failing node.

[0146] When a user submits a report issue, the global planning model is only invoked during initial planning or in case of structural failure. Most deterministic table operations are performed by the static executor, without requiring invocation of the language model. Local value matching errors are handled by the local repair model within the node-level context, with strictly limited input range, excluding the complete table, complete SQL, all intermediate results, and complete repair history.

[0147] In this embodiment, when multiple date formats cause the filtering node to fail, if the problem only affects the current date filtering node, the local repair model can generate a restricted date normalization function. This function must have fixed input and output signatures, can only be applied to the specified date column, and undergo syntax, security, and scope checks before execution. After passing the checks, the static executor re-executes the node and verifies the output.

[0148] If the date conversion still cannot meet the downstream aggregation requirements, or if it is found that the interpretation of the time range in the problem needs to be changed, the system will be upgraded to a global planning model, which will re-plan based on the problem semantics and the execution graph context.

[0149] This embodiment illustrates that the present invention achieves a unified optimization that balances data privacy protection, model call cost control, and error recovery capabilities under local deployment conditions.

[0150] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A table-based reasoning context routing method for locally deployed language models, characterized in that, include: Step 1: Obtain the natural language question and table data source; Step 2: Invoke the global planning model to generate a read-only SQL plan based on the natural language problem and the table data source; Step 3: Compile the read-only SQL plan into a directed acyclic execution graph, where each node in the execution graph records the operation type, declared input, output location, and output contract; Step 4: According to the node dependencies in the execution graph, the static executor executes the nodes whose parameters have been determined; Step 5: Verify the output of the completed node. If the verification is successful, store the node output as the input of the downstream node. If verification fails, record the evidence of failure and proceed with the partial repair or global replanning process based on the evidence of failure. Step 6: When all nodes in the execution graph pass the verification, generate the final answer.

2. The method according to claim 1, characterized in that, The global planning model calls the locally deployed large language model.

3. The method according to claim 1, characterized in that, The compilation method of the execution graph is as follows: First, the obtained SQL plan is parsed to translate the SQL language into operator-level execution steps, then transformed into a directed acyclic graph, and the conditional statements in the language are used as the basis and node parameters of the directed acyclic graph. Finally, the content in the SQL statement is transformed into the dependency relationship between graphs to obtain the specific content of the execution graph.

4. The method according to claim 1, characterized in that, The operation types include scanning, filtering, joining, aggregation, sorting, projection, limiting, comparison, arithmetic calculation, and format conversion.

5. The method according to claim 1, characterized in that, The declared input refers to the prior information that a node needs to support it in completing its task. Each node needs to declare the source of its dependent prior input data, including static input and dynamic output from other nodes.

6. The method according to claim 1, characterized in that, The output location is where the result of a node is saved after it has completed its task. Subsequent nodes can accurately retrieve this information by using the information at the output location.

7. The method according to claim 1, characterized in that, The output contract is to check whether the output content of each node meets the expected output format after the node has finished executing.

8. The method according to claim 1, characterized in that, In step 4, the static executor scans, filters, connects, sorts, aggregates, projects, and groups execution nodes with determined parameters according to the operation type and execution parameters declared by the nodes, and generates the execution results of the corresponding nodes.

9. The method according to claim 1, characterized in that, In step 5, the verification includes the output data type, column set, schema, result shape, NOT NULL constraint, scalar constraint, and security constraint.

10. The method according to claim 1, characterized in that, The verification method includes verifying the output of the completed node and verifying that all nodes pass the verification. Node output verification after execution: If no execution exception is thrown after the node is executed by the static executor and the output passes the output contract verification, the execution is considered successful; if the executor encounters a runtime exception or the node output fails the contract check, it will be considered an error; the system will check the operator based on the type, schema, shape and required fields of the node's output contract check result to determine whether it meets the requirements. All nodes pass verification: Nodes are run in the topological order of the execution graph. Each node must complete its execution and pass the output verification. The algorithm is considered to have succeeded when it confirms that the states of all nodes in the execution graph are valid. All nodes pass, the final node output satisfies the contract, and the normalized answer is successfully returned, indicating that the answer is generated normally at the execution and structural levels.

11. The method according to claim 10, characterized in that, In step 5, if the verification fails, the system determines whether the error meets the closure condition based on the failure evidence. The closure condition includes: Evidence conditions, namely, that the cause of failure can be explained solely by the failing node and its declared input; Repair conditions, namely, the candidate repair actions only modify the failed node and do not change other nodes, do not change the dependencies between nodes, and do not change the connection structure and the overall SQL plan; Budget conditions, namely, keeping the input of the local repair model within the preset token limit; When all the closure conditions are met, the local repair model is invoked to repair the failed node; If any of the closing conditions is not met, the global planning model is invoked to generate a revised SQL plan.

12. The method according to claim 11, characterized in that, The local repair model receives failed nodes, declaration inputs, representative values, error messages, and a list of allowed repair actions, but does not receive the complete execution history; the local repair model outputs structured repair candidates, and the representative values ​​include the first N samples of the failed node input dataset.

13. The method according to claim 12, characterized in that, The structured repair candidates include predicate repair and constraint function synthesis; Modify the predicates in the current file node through predicate repair; The constraint function is synthesized by determining the required data transformation type based on the execution failure node, declaring the function's input and output types, limiting the data range that the function can access and the basic operations that are allowed to be called, calling the local repair model to generate a function expression that satisfies the input and output constraints, and using a static executor to verify the function's return value type, output format, and execution result; after successful verification, the function is applied to the current execution node, the data transformation type is automatically inferred based on the mismatch between the output contract and the input type, and the data range is limited to the current node's input column and its derived columns.

14. The method according to claim 13, characterized in that, The global planning model receives the natural language question, the current SQL plan, failed nodes, relevant intermediate results, alternative columns, node dependencies, and evidence of previous local repair attempts, and generates a revised SQL plan. The revised SQL plan undergoes read-only checks, available table column checks, and compilation checks before execution.

15. A table-based reasoning context routing system for locally deployed language models, characterized in that, include: The input management module is used to receive natural language questions and at least one tabular data source, extract table names, column names, data types, sample values ​​and candidate key relationships, and generate a table summary; A global planning module is used to generate a read-only SQL plan or revise the SQL plan based on the natural language problem and the table summary. The SQL compilation module is used to compile the read-only SQL plan into an execution graph; The static execution module is used to perform deterministic table operations according to the node dependencies of the execution graph; The output validation module is used to validate the node output, checking whether the output meets one or more of the following criteria: data type, table mode, column set, result shape, non-null requirement, scalar requirement, and security constraint. The failure evidence collection module is used to record failure evidence when node verification fails; The context routing module is used to determine whether the closure condition is met based on the failure evidence, preset token restrictions, and allowed repair actions, and decide whether to enter local repair or global replanning accordingly. The local repair module is used to receive node-level evidence and a list of allowed actions, and generate structured repair candidates when the closure condition is met. The global replanning module is used to receive the current SQL plan and selective global evidence when the closure condition is not met, and modify column bindings, join keys, aggregation paths or SQL structures to generate a revised SQL plan; The results output module is used to normalize the verified execution graph results and output the final answer.

16. The system according to claim 15, characterized in that, The local repair module and the global planning module are implemented using the same basic locally deployed language model, but with different prompt templates, different context scopes, and different action permissions.

17. The system according to claim 15, characterized in that, It also includes a termination control module, which terminates when all nodes in the execution graph pass verification and generate the final answer; and terminates when the local repair limit is reached, the global replanning limit is reached, a duplicate SQL plan is detected, or an unchanged failure is detected.

Images