A decision equivalent risk priority auditing scheduling method and device and medium

Abstract

The application discloses a kind of decision equivalent risk priority audit scheduling method, device and medium, comprising: in response to multi-hop generation verification task start signal, determine verification task dependency graph, wherein, verification task dependency graph includes multiple verification nodes and the dependency relationship between each verification node;Based on verification task dependency graph, determine adjustment strategy, adjustment strategy is used to adjust the execution order of verification node from original execution order to dynamic scheduling order under the premise of maintaining final decision equivalent with original execution order, wherein, adjustment strategy includes: exchangeable scheduling strategy and conservative scheduling strategy;In response to adjustment strategy, generate scheduling instruction set, scheduling instruction set is used to schedule each verification node to execute verification according to dynamic scheduling order, and form the same final decision as original execution order according to the local verification result of each verification node.

Description

Technical Field

[0001] This invention relates to the field of decision equivalence risk priority audit technology, and more specifically, to a decision equivalence risk priority audit scheduling method, apparatus and medium. Background Technology

[0002] With the development of large language models, retrieval-enhanced generation, tool calls, and intelligent agent systems, a single generation output usually contains multiple interrelated fact units, reasoning steps, or tool call nodes. Each node needs to be locally verified separately before they are combined to form a final decision.

[0003] Existing multi-hop generation and verification systems typically execute verification nodes in a fixed order, according to the generation order, dependency graph topology order, or task enqueue order. While some systems can stop subsequent verifications after the first node fails, thus achieving basic early stopping, such fixed-order or simple priority scheduling only considers a single-dimensional factor and fails to perform formal analysis of data dependencies, state dependencies, evidence dependencies, and decision dependencies between nodes before verification execution. It cannot identify whether the final decision can still be maintained after changing the execution order. Therefore, it is easy to see the phenomenon that high-cost, low-rejection-probability nodes are executed first for verification objects that will inevitably be rejected, while high-rejection-probability nodes are ranked later. This leads to serious waste of computing resources such as token consumption, GPU / video memory usage, external API call costs, and decision latency.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides a method, apparatus, and medium for scheduling risk-priority audits based on decision equivalence, which at least solves the technical problem that existing multi-hop generation verification systems cannot dynamically optimize the execution order to reduce computational resource consumption while maintaining complete equivalence with the final decision of the original execution order due to the fixed execution order of verification tasks or only adjusting according to ordinary priority.

[0006] According to one aspect of the present invention, in order to achieve the above objective, a decision equivalence risk priority audit scheduling method is provided, comprising:

[0007] In response to the multi-hop generation verification task start signal, a verification task dependency graph is determined, wherein the verification task dependency graph includes multiple verification nodes and the dependency relationships between each verification node;

[0008] Based on the verification task dependency graph, an adjustment strategy is determined. The adjustment strategy is used to adjust the execution order of the verification nodes from the original execution order to the dynamic scheduling order while maintaining equivalence with the final decision of the original execution order. The adjustment strategy includes: exchangeable scheduling strategy and conservative scheduling strategy.

[0009] In response to the adjustment strategy, a scheduling instruction set is generated. The scheduling instruction set is used to schedule each verification node to perform verification in a dynamic scheduling order, and form a final decision that is the same as the original execution order based on the local verification results of each verification node.

[0010] Further, the verification task dependency graph is determined, including:

[0011] Obtain the object to be verified, and freeze the candidate versions of the object to be verified, the input snapshots of each verification node, and the evidence snapshots;

[0012] Each verification node is decomposed to determine its data dependencies, state dependencies, evidence dependencies, and judgment dependencies.

[0013] A verification task dependency graph is constructed based on data dependency, state dependency, evidence dependency, and judgment dependency.

[0014] Furthermore, based on the verification task dependency graph, an adjustment strategy is determined, including:

[0015] Exchangeability analysis is performed on each verification node to determine exchangeable verification nodes. Exchangeable verification nodes are those that simultaneously meet the following conditions: no ancestor-descendant dependency relationship, bound to the same frozen candidate version, input snapshot is consistent with evidence snapshot, no conflict between read and write sets, no shared mutable hidden state, and no external side effects that affect each other.

[0016] Based on the exchangeable verification nodes, determine the exchangeable scheduling strategy;

[0017] When there are no interchangeable verification nodes, or when it cannot be proven that interchangeable verification nodes satisfy the decision equivalence constraint, a conservative scheduling strategy is determined.

[0018] Furthermore, based on the verification task dependency graph, determining the adjustment strategy also includes:

[0019] Determine the current set of executable nodes;

[0020] Under the exchangeable scheduling policy, the scheduling attribute information of each executable node is estimated, wherein the scheduling attribute information includes at least one of the following: rejection risk, execution resource cost, subsequent release benefit, and prediction confidence.

[0021] Based on scheduling attribute information, the scheduling priority of each executable node is determined;

[0022] The dynamic scheduling order is determined based on scheduling priority.

[0023] Furthermore, the scheduling attribute information of each executable node is estimated, including:

[0024] Based on historical veto records, verification node types, evidence characteristics, and topological locations, veto risks are determined.

[0025] The execution resource cost is determined based on the expected latency, token consumption, GPU usage, video memory usage, CPU usage, network cost, and external API call cost.

[0026] Based on the estimated workload of subsequent verification nodes that can be canceled after a verification node generates a veto, the subsequent release revenue is determined.

[0027] The confidence level of the prediction is determined based on the reliability of the estimates of veto risk and execution resource costs.

[0028] Furthermore, based on scheduling attribute information, the scheduling priority of each executable node is determined, including:

[0029] Scheduling priority is determined by the ratio of the product of veto risk, subsequent release benefits, and prediction confidence level to the execution resource cost.

[0030] In response to scheduling priority, a target verification node is selected from the current set of executable nodes;

[0031] Add the target verification node to the dynamic scheduling order.

[0032] Furthermore, in response to the adjustment strategy, after generating the scheduling instruction set, it also includes:

[0033] In response to a hard rejection by any verification node, update the current partial assignment;

[0034] Based on the current partial assignment, perform a judgment certainty check to determine the final judgment status;

[0035] In response to the final judgment status being determined as "judgment confirmed", the cancellation closure is determined according to the verification task dependency graph, and the verification nodes to be cancelled in the cancellation closure are cancelled.

[0036] The late verification result was refused to be included in the final judgment.

[0037] Furthermore, based on the verification task dependency graph, the cancellation closure is determined, and the verification nodes to be cancelled in the cancellation closure are cancelled, including:

[0038] Calculate the cancellation closure based on the verification task dependency graph, decision function, node purpose of each verification node, and shared reference count;

[0039] Send a cancellation token to a running, cancel-enabled, pending-cancellation verification node;

[0040] New, unnecessary verification nodes are prohibited from joining the queue;

[0041] For external tasks that do not support immediate cancellation, revoke their write permissions for results and perform version verification and snapshot verification on the returned results.

[0042] According to one embodiment of the present invention, a decision equivalence risk priority audit scheduling device is also provided, comprising:

[0043] A response module is used to respond to a multi-hop generation verification task start signal and determine a verification task dependency graph, wherein the verification task dependency graph includes multiple verification nodes and the dependency relationships between the verification nodes.

[0044] The determination module is used to determine an adjustment strategy based on the verification task dependency graph. The adjustment strategy is used to adjust the execution order of the verification nodes from the original execution order to the dynamic scheduling order while maintaining equivalence with the final decision of the original execution order. The adjustment strategy includes: a swappable scheduling strategy and a conservative scheduling strategy.

[0045] A generation module is used to generate a scheduling instruction set in response to the adjustment strategy. The scheduling instruction set is used to schedule each of the verification nodes to perform verification according to the dynamic scheduling order, and to form a final decision that is the same as the original execution order based on the local verification results of each of the verification nodes.

[0046] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is executed, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of the present invention.

[0047] In this embodiment of the invention, by constructing a verification task dependency graph under the premise of freezing candidate versions and the inputs and evidence snapshots of each node, the execution order of verification nodes is dynamically adjusted only after the exchangeability analysis and decision equivalence constraint proof are passed. Furthermore, after any node generates a hard rejection, the pending execution node that no longer affects the final decision is safely canceled according to the dependency graph. This achieves complete equivalence between the adjusted dynamic scheduling order and the original execution order in a sample-by-sample final decision, meaning that the final acceptance or rejection decision for the same verification object remains consistent under both orders. Based on this, by prioritizing the execution of exchangeable verification nodes with high rejection risk, low execution resource cost, and the ability to release subsequent workloads after failure, the system... The system can achieve the same final decision as the original order with fewer average verification steps, lower token consumption, lower GPU / memory usage, fewer external API calls, and shorter decision latency. At the same time, it automatically degrades to the original topological order or conservative serial order when it cannot prove dependency security or decision equivalence. Under the premise of ensuring decision correctness, it significantly reduces the average computing resource consumption of multi-hop generation verification. This solves the technical problem of existing multi-hop generation verification systems, which cannot dynamically optimize the execution order to reduce computing resource consumption while maintaining the final decision equivalence with the original execution order, because the execution order of verification tasks is fixed or only adjusted according to ordinary priority. Attached Figure Description

[0048] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0049] Figure 1 This is a flowchart of a decision equivalence risk priority audit scheduling method according to one embodiment of the present invention;

[0050] Figure 2 This is a system functional module and data flow relationship diagram in a decision equivalence risk priority audit scheduling method according to one embodiment of the present invention;

[0051] Figure 3 This is a schematic diagram of the verification task dependency graph, exchangeable nodes, and legend in a decision equivalence risk priority audit scheduling method according to one embodiment of the present invention.

[0052] Figure 4 This is a flowchart of the main process of decision equivalence risk priority audit scheduling in a decision equivalence risk priority audit scheduling method according to one embodiment of the present invention;

[0053] Figure 5 This is a flowchart of the security cancellation and resource release after decision determination in a decision equivalence risk priority audit scheduling method according to one embodiment of the present invention;

[0054] Figure 6 This is a structural block diagram of a decision equivalence risk priority audit scheduling device according to one embodiment of the present invention. Detailed Implementation

[0055] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0056] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0057] According to an embodiment of the present invention, a method for scheduling audits based on decision equivalence risk is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0058] This method embodiment can be executed in an electronic device or similar computing device that includes a memory and a processor. Taking operation on a terminal as an example, the terminal may include one or more processors (processors may include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), digital signal processing (DSP) chips, microcontroller units (MCUs), field-programmable gate arrays (FPGAs), neural network processors (NPUs), tensor processors (TPUs), artificial intelligence (AI) type processors, etc.) and a memory for storing data. Optionally, the terminal may also include transmission devices, input / output devices, and display devices for communication functions. Those skilled in the art will understand that the above structural description is merely illustrative and does not limit the structure of the terminal. For example, the terminal may include more or fewer components than described above, or have a different configuration than described above.

[0059] The memory can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the decision equivalence risk priority audit scheduling method in this embodiment of the invention. The processor executes various functional applications and data processing by running the computer program stored in the memory, thereby implementing the aforementioned decision equivalence risk priority audit scheduling method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0060] The transmission device is used to receive or send data via a network. Specific examples of the network mentioned above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0061] Display devices can be, for example, touchscreen liquid crystal displays (LCDs) and touch displays (also referred to as "touchscreens" or "touch displays"). The LCD allows users to interact with the user interface of the mobile terminal. In some embodiments, the mobile terminal has a graphical user interface (GUI), which allows users to interact with the GUI through finger contact and / or gestures on a touch-sensitive surface. Optional human-computer interaction functions include: creating web pages, drawing, word processing, creating electronic documents, playing games, video conferencing, instant messaging, sending and receiving emails, call interfaces, playing digital video, playing digital music, and / or web browsing, etc. Executable instructions for performing the above human-computer interaction functions are configured / stored in one or more processor-executable computer program products or readable storage media.

[0062] Figure 1 This is a flowchart of a decision equivalence risk priority audit scheduling method according to one embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0063] Step S110: In response to the multi-hop generation verification task start signal, determine the verification task dependency graph, wherein the verification task dependency graph includes multiple verification nodes and the dependency relationships between each verification node, the specific content of which is as follows:

[0064] In step S110, in a multi-hop generation verification scenario, a verification task start signal is triggered upon receiving the object to be verified. The object to be verified includes, but is not limited to, multi-hop generation results, retrieval enhancement generation results, tool invocation plans, intelligent agent task execution records, and composite fact statements. In response to this start signal, the object to be verified is first decomposed into multiple interconnected local verification units according to its internal logical structure, with each local verification unit corresponding to a verification node.

[0065] During this process, candidate versions of the object to be verified, input snapshots of each verification node, and evidence snapshots are simultaneously frozen to ensure that all subsequent verification nodes are executed in the same frozen state, providing a deterministic basis for determining the equivalence of the execution order and proving the equivalence of the final judgment. Each verification node records at least the node identifier, candidate version identifier, input snapshot identifier, evidence snapshot identifier, verifier type, predecessor node set, successor node set, side effect category, read set, write set, node state, and local verification result.

[0066] Based on this, a verification task dependency graph is established according to the logical relationships between each verification node. Specifically, the dependencies between verification nodes are analyzed from multiple dimensions: First, data dependencies are determined based on the input sources and output flows of verification nodes. If the output of one verification node is a necessary input for another verification node, then there is a data dependency edge between them. Second, state dependencies are determined based on the read and write sets of each verification node for shared state objects. If the write set of one verification node intersects with the read or write set of another verification node and they share a variable state, then there is a state dependency edge between them. Third, evidence dependencies are determined based on the generation and consumption relationships of evidence objects. If the evidence generated by one verification node is used as the verification basis by another verification node, then there is an evidence dependency edge between them. Finally, decision dependencies are determined based on the convergence position and participation method of the local verification results of each verification node in the global decision function.

[0067] The extraction of the aforementioned dependencies can be achieved through various engineering methods. For structured workflow description files, explicitly declared fields such as `depends_on`, `input_from`, `output_to`, `precondition`, and `join` are directly parsed. For program scripts or proxy code, dependencies are extracted through control flow graph analysis, data flow analysis, function call graph analysis, and read-write set analysis. For unstructured natural language plans, entity and event extraction, coreference resolution, temporal relationship identification, and language model-based constrained dependency extraction methods are used to output the extraction results as a structured description in a fixed format. Furthermore, the source identifier and extraction confidence of each dependency edge are recorded to distinguish whether the edge originates from explicit workflow declarations, static analysis, rule derivation, model extraction, or conservative completion.

[0068] After the dependency graph is constructed, further integrity and consistency checks are performed, including schema integrity checks, reference closure verification, loop detection, unresolved field checks, and original order consistency checks. When dependency resolution fails, dependency pointers are not unique, model extraction confidence is low, read / write sets are unknown, or there is ambiguity as to whether an output is a necessary input for a successor node, conservative strong dependency edges are established between the relevant nodes, or they are merged into non-reorderable order groups. Only after obtaining static proof, rule derivation, or valid exchange certificates are the corresponding strong dependency edges allowed to be downgraded to weak order edges. The constructed verification task dependency graph provides the graph structure foundation for subsequent commutativity analysis, scheduling priority calculation, and dependency propagation cancellation after hard rejection.

[0069] Step S120: Based on the verification task dependency graph, determine the adjustment strategy. The adjustment strategy is used to adjust the execution order of the verification nodes from the original execution order to the dynamic scheduling order while maintaining equivalence with the final decision of the original execution order. The adjustment strategy includes: a swappable scheduling strategy and a conservative scheduling strategy, the details of which are as follows:

[0070] In step S120, after constructing the verification task dependency graph, an adjustment strategy is determined based on the dependency graph. This adjustment strategy is used to adjust the execution order of the verification nodes from the original execution order to a dynamic scheduling order, while maintaining equivalence to the final decision of the original execution order.

[0071] Specifically, a commutativity analysis is first performed on each verification node in the verification task dependency graph to determine whether any two verification nodes can change their relative execution order without altering the final decision. Two verification nodes are considered commutable only if they simultaneously meet all of the following conditions: there is no ancestor-descendant dependency between the two nodes, i.e., there is no direct or indirect data dependency, state dependency, evidence dependency, or decision dependency that must be completed first; the two nodes are bound to the same freeze candidate version or the same immutable freeze candidate object; the input snapshot identifier and evidence snapshot identifier of both nodes are fixed, and the execution result of one node will not change the input set or evidence set of the other node; the write set of the two nodes does not conflict with the read set and write set of the other node, or conflicting objects are managed using read-only snapshots, versioned isolation, or copy-on-write mechanisms; the two nodes do not share mutable hidden states, random states, or session cursors that change with the execution order; and the two nodes do not produce external side effects that affect the other node. For nodes with side effects, delayed execution, transactional prepare / commit / abort protocols, or idempotent interfaces are required before they can participate in restricted reordering.

[0072] Exchangeability can be calculated on a node-by-node basis or determined in batches by equivalence class. For multiple nodes that share the same frozen version, have no mutual dependencies, no side effects, and use fixed evidence snapshots, they can be grouped into the same exchangeable node group.

[0073] Based on this, adjustment strategies are determined, including exchangeable scheduling strategies and conservative scheduling strategies. When exchangeable verification nodes exist in the verification task dependency graph, and it can be proven that the adjusted execution order satisfies the decision equivalence constraint, the exchangeable scheduling strategy is adopted. The decision equivalence constraint requires that the adjusted dynamic scheduling order and the original execution order produce the exact same final decision under all possible combinations of local verification results. That is, for any combination of local results in the same frozen verification state, the final acceptance or rejection decision under the two orders remains consistent, rather than merely having similar statistical accuracy.

[0074] When employing a swappable scheduling strategy, at each scheduling moment, a set of currently executable nodes is constructed from all currently unexecuted verification nodes. All strong dependencies of each verification node in this set have been completed, and the frozen version, input snapshot, evidence snapshot, and swap conditions remain valid. Then, the next verification node to be executed is selected from this set according to scheduling priority, gradually generating a dynamic scheduling order. For weakly ordered edges—that is, order constraints originating from the original generation order, historical workflow, or enqueue order but not yet proven to be necessary for data dependency, state dependency, evidence dependency, or decision—the system allows the target node to bypass its original order predecessors and participate in scheduling after obtaining the edge removal certificate and the relevant node simultaneously possessing a valid swap certificate. If any verification fails, the weakly ordered edge is treated as a strong dependency edge in this scheduling and cannot be crossed.

[0075] When no exchangeable verification nodes exist, or it cannot be proven that exchangeable verification nodes satisfy the decision equivalence constraint, a conservative scheduling strategy is adopted. Specifically, dynamic reordering is stopped and the conservative scheduling strategy is reverted when any of the following situations occur: incomplete dependencies, the existence of loops, or inability to determine whether the predecessor output is a necessary input for the successor node; changes occur in the candidate version, input snapshot, or evidence snapshot used by the node; conflicts exist in the read / write set, shared variable hidden states, or random states cannot be isolated; the node has unregistered or uncompensable external side effects; the global decision rules change, or it cannot be proven that canceling the node does not affect the final decision; the confidence level of the risk or cost estimate is below the threshold; the exchange certificate expires, the strategy version does not match, or the audit log cannot be completely generated.

[0076] When employing a conservative scheduling strategy, all verification nodes are executed in the original topology order, or in a conservative serial order, with parallel execution only permitted between clearly independent nodes. While this conservative scheduling strategy may reduce scheduling efficiency, it ensures that even under uncertainties such as unclear dependencies, changes in evidence snapshots, the existence of unregistered side effects, or insufficient confidence in the scheduling model, the final decision remains identical to the original execution order.

[0077] Regardless of whether a commutative or conservative scheduling strategy is adopted, the adjusted dynamic scheduling order must satisfy the following equivalence conditions: the dynamic scheduling order satisfies all non-reorderable strong dependency edges in the verification task dependency graph; all nodes executed early in the dynamic scheduling order use the same frozen candidate versions, input snapshots, and evidence snapshots as the original execution order; and the execution of verification nodes does not modify local decision rules, decision thresholds, verifier versions, or global merging rules. Only when all the above conditions are met is the dynamic scheduling order allowed to be actually executed; otherwise, it must revert to the conservative scheduling strategy. By differentiating and switching between the two strategies, the adjustment strategy maximizes the optimization of the execution order while ensuring the equivalence of the final decision.

[0078] Step S140: In response to the adjustment strategy, a scheduling instruction set is generated. The scheduling instruction set is used to schedule each verification node to perform verification according to the dynamic scheduling order, and to form a final decision that is the same as the original execution order based on the local verification results of each verification node. The specific content is as follows:

[0079] In step S140, after determining the adjustment strategy, a scheduling instruction set is generated in response to the adjustment strategy. When a commutative scheduling strategy is adopted, the scheduling instruction set schedules each verification node to perform verification in sequence according to the dynamic scheduling order generated after verification through commutativity analysis and decision equivalence constraints. Specifically, at each scheduling moment, a target verification node is selected from the current set of executable nodes according to scheduling priority, added to the dynamic scheduling order, and a corresponding execution instruction is generated. The current set of executable nodes consists of all verification nodes that have not yet been completed and whose entire set of predecessor strongly dependent nodes has been completed, and the frozen version, input snapshot, evidence snapshot, and exchange conditions of each verification node in the set remain valid. The scheduling priority is determined based on at least two of the following: the rejection risk of each verification node, the execution resource cost, and the subsequent workload that can be released after the node rejects. Verification nodes with higher rejection risk, lower execution resource cost, and larger subsequent workload that can be released after failure are selected for priority execution. When the scheduling priorities of multiple verification nodes are similar, verification nodes on the critical path, cache hit nodes, or nodes that can be merged into the same micro-batch for parallel execution are selected first. When a conservative scheduling strategy is adopted, the scheduling instruction set schedules each verification node to perform verification according to the original topology order or a conservative serial order. Parallel execution is only allowed between clearly independent verification nodes to ensure the correctness of the final decision when dependencies are unclear or decision equivalence cannot be proven. The scheduling instruction set is also dynamically updated according to the completion status of the verification nodes at runtime. Whenever a verification node completes its execution, the current set of executable nodes and scheduling priorities are recalculated until all necessary verification nodes affecting the final decision have completed their execution or the final decision has been determined.

[0080] Each verification node, during verification, uses the same frozen candidate versions, input snapshots, and evidence snapshots as the original execution order, and invokes the corresponding verifier to perform local verification within an independent execution context. The verifiers include one or more of the following: semantic verifier, structural verifier, formal verifier, tool verifier, or manual review interface. Each verifier declares its execution isolation descriptor during registration, including verifier version, state mode, context scope, sandbox identifier, state root, random seed range, allowed resource set, read set, write set, and isolation policy version. The state mode is declared as stateless, read-only snapshot, or isolation variable. Each verification node is allocated an independent inference context, key-value cache handle, random number generator instance, retrieval session, and tool session during execution, or creates a write-on-write copy from the same frozen parent snapshot, ensuring that execution between different verification nodes does not interfere with each other. After the verification node completes its execution, it writes the local verification result to the current part assignment.

[0081] During the execution of verification nodes, if any verification node generates a hard rejection, it does not immediately trigger global cancellation. Instead, the hard rejection result is first written into the current part assignment, and the decision determinism checker is called to update the final decision state. The decision determinism checker determines whether the final decision has been determined based on the current part assignment, the set of pending nodes, the decision rule, and the version. For global conjunctive non-compensatory decisions, a hard rejection result from any necessary local verification node can cause the global decision to enter a rejected determination state. For disjunctive decisions, threshold decisions, hierarchical gating decisions, or other complex decision rules, rule templates, Boolean decision graphs, or solvers are used for real-time determination. If any possible combination of results for all pending nodes under the current part assignment keeps the final decision unchanged, the final decision is declared determined, and the deterministic proof type, solution result, and proof hash are written into the decision state record. If the solver returns unknown, times out, or the proof version does not match, the final decision must not be declared determined, and verification nodes that may still affect the final decision continue to be executed. While the final decision is pending, only branch-exclusive nodes that have been proven to belong solely to the failed branch and whose outcomes do not affect other branches or the final decision can be cancelled, and the proof of local irrelevance can be recorded in the proof record.

[0082] Once the final decision is determined, a cancellation closure is calculated based on the verification task dependency graph, the decision function, the purpose of each verification node, and the shared reference count. This cancellation closure includes all verification nodes that no longer affect the final decision. Specifically, completed verification nodes, verification nodes determined to be no longer needed, and verification nodes serving only failed branches are excluded from or included in the cancellation closure. Simultaneously, the shared reference count distinguishes between currently exclusive candidate verification nodes and multiple candidate shared verification nodes. For shared nodes, only the current candidate's reference or subscription is released. The underlying shared task is cancelled only when the shared reference count drops to zero and the node meets the cancellation safety conditions. A cancellation token is generated and sent to running verification nodes that support cancellation, preventing new unnecessary verification nodes from joining the queue. Queued verification nodes that have not yet started are marked as cancelled or skipped. For external tasks that do not support immediate cancellation, revoke their write permissions for results and require the returned results to carry candidate version identifiers, scheduling instance identifiers, and evidence snapshot identifiers. Return results that arrive after the final decision is made, or that are version mismatched, snapshot mismatched, or whose cancellation epoch is lagging behind, are only allowed to enter the audit area and must not participate in the final aggregation. After the task is stopped or the results are isolated, release the computation and invocation resources.

[0083] When all necessary verification nodes affecting the final decision pass, an acceptance decision is formed; when any hard veto determines the global decision, a rejection decision is formed. Throughout this process, regardless of whether an exchangeable scheduling strategy or a conservative scheduling strategy is used, because each verification node uses the same frozen candidate version, input snapshot, evidence snapshot, and verifier, and the execution order is changed only without violating dependencies and decision equivalence constraints, the final decision is identical to the decision under the original execution order. Simultaneously, the original execution order, the actual execution order, the set of executable nodes at each scheduling moment, priority values, exchange reasons, exchange certificates, scheduling strategy version, candidate version identifier, evidence snapshot identifier, local verification results of each verification node, cancellation scope, and strategy version records are recorded as audit logs to support subsequent audit replay and decision equivalence verification.

[0084] Based on steps S110 to S140 above, in this embodiment of the invention, a verification task dependency graph is constructed under the premise of freezing candidate versions and the inputs and evidence snapshots of each node. The execution order of verification nodes is dynamically adjusted only after the commutativity analysis and decision equivalence constraint proof are passed. After any node generates a hard rejection, the pending execution node that no longer affects the final decision is safely canceled according to the dependency graph. This achieves complete equivalence between the adjusted dynamic scheduling order and the original execution order in sample-by-sample final decision, meaning that the final acceptance or rejection decision for the same verification object remains consistent under the two orders. On this basis, priority is given to executing nodes with high rejection risk, low execution resource cost, and large subsequent workload release after failure. By exchanging verification nodes, the system can obtain the same final decision as the original order with fewer average verification steps, lower token consumption, lower GPU / memory usage, fewer external API calls, and shorter decision latency. At the same time, it automatically degrades to the original topological order or conservative serial order when it cannot prove dependency security or decision equivalence. This significantly reduces the average computational resource consumption of multi-hop generation verification while ensuring decision correctness. It solves the technical problem of existing multi-hop generation verification systems, which cannot dynamically optimize the execution order to reduce computational resource consumption while maintaining complete equivalence of the final decision with the original execution order due to the fixed execution order of verification tasks or only adjusting according to ordinary priority.

[0085] The judgment equivalence risk priority audit scheduling method of the present invention determines the verification task dependency graph, including: obtaining the object to be verified, freezing the candidate versions of the object to be verified, the input snapshots and evidence snapshots of each verification node; decomposing each verification node to determine the data dependency relationship, state dependency relationship, evidence dependency relationship and judgment dependency relationship of each verification node; and constructing the verification task dependency graph based on the data dependency relationship, state dependency relationship, evidence dependency relationship and judgment dependency relationship.

[0086] By freezing the candidate versions of the object to be verified and the input snapshots and evidence snapshots of each verification node, and combining the dependencies of four dimensions—data dependency, state dependency, evidence dependency, and decision dependency—a verification task dependency graph is constructed. This provides a deterministic graph structure foundation for subsequent interchangeability determination and decision equivalence scheduling, thereby ensuring that the adjustment of the execution order will not compromise the correctness of the final decision.

[0087] Furthermore, based on the verification task dependency graph, an adjustment strategy is determined, including: performing commutativity analysis on each verification node to identify commutable verification nodes, where a commutable verification node is a verification node that simultaneously satisfies the following conditions: no ancestor-descendant dependency relationship, bound to the same frozen candidate version, input snapshot consistent with evidence snapshot, no conflict in read / write sets, no shared mutable hidden state, and no mutually influencing external side effects; based on commutable verification nodes, a commutative scheduling strategy is determined; when no commutable verification node exists, or when it cannot be proven that a commutable verification node satisfies the decision equivalence constraint, a conservative scheduling strategy is determined. This ensures that the execution order is dynamically adjusted only when all commutativity conditions and decision equivalence constraints are met, thus ensuring that the final decision is completely consistent with the original order, while maintaining the correctness of the decision by reverting to the conservative scheduling strategy when the conditions cannot be met.

[0088] Furthermore, based on the verification task dependency graph, the adjustment strategy is determined, which also includes: determining the current set of executable nodes; estimating the scheduling attribute information of each executable node under the exchangeable scheduling strategy, wherein the scheduling attribute information includes at least one of the following: rejection risk, execution resource cost, subsequent release benefit, and prediction confidence; determining the scheduling priority of each executable node based on the scheduling attribute information; and determining the dynamic scheduling order based on the scheduling priority. This ensures that, while guaranteeing decision equivalence, verification nodes with higher expected rejection benefits, lower costs, and the ability to release more subsequent workload after failure are prioritized for execution, effectively reducing average verification latency and resource consumption.

[0089] Furthermore, the scheduling attribute information of each executable node is estimated, including: determining the veto risk based on historical veto records, verifier node type, evidence characteristics, and topological location; determining the execution resource cost based on expected latency, token consumption, GPU usage, video memory usage, CPU usage, network cost, and external API call cost; determining the subsequent release benefit based on the expected workload of subsequent verifier nodes that can be canceled after a verifier node generates a veto; and determining the prediction confidence level based on the reliability of the estimates of veto risk and execution resource cost. This provides a comprehensive, detailed, and quantifiable decision-making basis for node priority ranking under the exchangeable scheduling strategy, improving the accuracy of dynamic scheduling in identifying nodes with high veto benefits and low execution costs.

[0090] Furthermore, based on scheduling attribute information, the scheduling priority of each executable node is determined, including: determining the scheduling priority based on the ratio of the product of rejection risk, subsequent release benefit, and predicted confidence level to execution resource cost; responding to the scheduling priority, selecting a target verification node from the current set of executable nodes; and adding the target verification node to the dynamic scheduling order. This prioritizes scheduling verification nodes with high expected rejection benefits and low execution costs, maximizing the verification benefit per unit of resource investment while maintaining decision equivalence, accelerating the formation of the final decision, and reducing unnecessary computational resource consumption.

[0091] Furthermore, in response to the adjustment strategy and after generating the scheduling instruction set, the process also includes: updating the current partial assignment in response to any verification node generating a hard veto; performing a decision determinism check based on the current partial assignment to determine the final decision state; in response to the final decision state being that the decision has been determined, determining the cancellation closure according to the verification task dependency graph, and canceling the verification nodes to be canceled in the cancellation closure; and rejecting late verification results from being written into the final decision. This effectively blocks invalid nodes from continuing to execute and prevents pollution of the final decision while ensuring that the equivalence of the decisions is not violated, further reducing the consumption of invalid computing resources.

[0092] Furthermore, based on the verification task dependency graph, a cancellation closure is determined, and the verification nodes to be cancelled within the cancellation closure are cancelled. This includes: calculating the cancellation closure based on the verification task dependency graph, the decision function, the node purpose of each verification node, and the shared reference count; sending cancellation tokens to running verification nodes that support cancellation; prohibiting new unnecessary verification nodes from being enqueued; and revoking the write permissions of external tasks that do not support immediate cancellation, and performing version verification and snapshot verification on the returned results. This ensures that multiple candidate shared tasks are not mistakenly cancelled, achieving thorough and secure cancellation and resource release of invalid tasks after the decision direction has been determined, while guaranteeing that invalid tasks are not mistakenly cancelled.

[0093] Another method for prioritizing audit scheduling based on decision equivalence risk according to one embodiment of the present invention, such as Figures 2-5 As shown, the method includes the following steps:

[0094] See Figure 2The decision equivalence risk-priority audit scheduling system in this embodiment can be composed of a main processing chain consisting of a task parsing and freezing module M1, a dependency graph construction module M2, an exchangeability analysis module M3, a risk and cost estimation module M4 / M5, an equivalence constraint scheduling module M6, and a verification execution and convergence module M7. It also provides secure cancellation, full-process auditing, and anomaly degradation capabilities through a dependency propagation cancellation module M8, an audit and replay module M9, and a degradation and rollback interface M10. These modules can be deployed either on the same computing node or distributed along the boundaries of the verifier, scheduler, audit storage, and external tool services. Regardless of the deployment method, the same frozen candidate version, the same input snapshot, and the same evidence snapshot are used as the decision equivalence benchmark for this scheduling instance.

[0095] See Figure 3 In the task dependency graph, solid lines represent uncrossable strong dependency edges, dashed lines represent weakly ordered edges that can be removed after the edge removal condition is met and a valid proof is obtained, and shaded nodes represent executable verification nodes in the current Ready set. Figure 3 Taking v1 to v6 as an example, after v1 is completed, both v2 and v3 have the prerequisite for execution. If there is only a removable weak order edge between v2 and v3, and both pass the commutativity check, then both can enter the Ready set at the same time, and no longer mechanically follow the original order, but the risk priority determines whether v2 or v3 is executed first.

[0096] See Figure 4 The overall execution process of this embodiment can be summarized as follows: freezing candidates and establishing a verification task dependency graph; identifying strong dependency edges and weak order edges and determining swapping nodes; estimating rejection risk, execution cost, and resource release benefits; calculating the legal Ready set and risk priority; dynamically scheduling execution under decision equivalence constraints; executing safe cancellation after the decision enters the absorption state; and completing auditing, equivalence verification, and risk degradation. The following steps S201 to S212 are... Figure 4 Further refinement of each processing stage, with multiple steps corresponding to... Figure 4 The number of sub-steps in the specific implementation is not limited by the number of boxes in the diagram, even within the same processing stage.

[0097] See Figure 5When any verification node outputs a hard rejection, the system does not immediately cancel all other nodes. Instead, it first determines whether the global decision has entered the absorption state. Only when the existing partial verification results are sufficient to ensure that the final decision is no longer affected by the results of other unresolved nodes, does it calculate the exclusive closure of decision-irrelevant nodes and failed branches. Then, it performs cancellation, revocation of write permissions, and result isolation for queued tasks, in-transit tasks, and late results, thereby releasing resources such as GPUs, tokens, and APIs. Therefore, the efficiency gains obtained through risk-priority scheduling do not come at the expense of the correctness of the final decision.

[0098] Step S201: Obtain the object to be verified, establish a scheduling instance and freeze candidate versions, input snapshots and evidence snapshots.

[0099] When the verification process starts, the task parsing and freezing module M1 receives the multi-hop generation verification task start signal and obtains the object to be verified. The object to be verified can be a multi-hop generation result, a retrieval enhancement generation result, a tool invocation plan, a smart agent task execution record, a composite fact statement, or other objects whose final acceptance or rejection result is jointly determined by multiple local judgments. M1 establishes a unique scheduling instance identifier, schedule_instance_id, for this verification process and records the candidate object identifier, policy version, decision function version, and validator set version, which are used to identify the same scheduling instance during subsequent execution, cancellation, and auditing processes.

[0100] M1 decomposes the object to be verified into multiple local verification units according to its semantic structure, data flow structure, tool call structure, or pre-configured workflow structure, and maps each local verification unit to a verification node v_i. Each verification node corresponds to at least one explicit local decision target, such as factual support, entity relationship consistency, time conditions, structural legality, tool parameter legality, code or formula constraints, permission constraints, or manual review items. For composite verification units that cannot be safely decomposed, they can be retained as a composite node that cannot be further rearranged to avoid changing the local verification semantics due to excessive decomposition.

[0101] When node decomposition is complete, M1 freezes the candidate version `candidate_version`, ensuring that all subsequent nodes perform verification on the same immutable candidate object. Freezing can be achieved using one or more of the following methods: immutable object identifier, content hash, version number, or content addressing root. If the candidate content is modified during verification, the modified object should be considered a new candidate version, and a new scheduling instance should be established. Partial verification results already obtained in the old scheduling instance must not be directly written into the final decision of the new candidate version.

[0102] Simultaneously, M1 generates an input snapshot (input_snapshot) and an evidence snapshot (evidence_snapshot) for each verification node. The input snapshot is used to fix the local text, entity identifiers, relation types, time intervals, structured schemas, preconditions, shared state read-only views, and tool execution status necessary for node execution; the evidence snapshot is used to fix the retrieved document fragments, knowledge graph triples, database query results, external API responses, rule base versions, and other factual evidence. For nodes requiring online retrieval, the retrieval query and retrieval version identifier can be generated first, and then the actual retrieval results used for verification can be fixed into this evidence snapshot.

[0103] To ensure a comparable basis for the results before and after the order adjustment, each verification node is bound to candidate_version_id, input_snapshot_id, and evidence_snapshot_id. Before the node actually starts, the verification execution and aggregation module M7 re-verifies the above three identifiers; if any identifier is inconsistent with the frozen state of the scheduling instance, the node must not execute according to the original exchange certificate, but should trigger re-analysis or enter conservative scheduling through the downgrade and rollback interface M10.

[0104] Each validation node also records fields such as node_id, validator_type, validator_version, predecessor_set, successor_set, read_set, write_set, side_effect_class, state_mode, node_status, and local_result. Among these, state_mode can at least distinguish between stateless, read-only snapshot states, and isolated mutable states; node_status can at least include WAITING, READY, QUEUED, RUNNING, PASSED, VETOED, CANCELLED, and IGNORED. This information collectively constitutes the basic metadata required for subsequent dependency analysis, exchange judgment, risk estimation, and secure cancellation.

[0105] Step S202: Construct a verification task dependency graph from four dimensions: data dependency, state dependency, evidence dependency, and decision dependency.

[0106] The dependency graph construction module M2 uses the set of verification nodes V obtained in step S201 as the vertex set, and constructs the edge set E according to the necessary order relationship between the nodes, thereby obtaining the verification task dependency graph G=(V,E). This embodiment does not simply regard all the original generation order as immutable dependencies, but distinguishes between strong dependencies that truly affect the semantics of node input or decision, and weak order constraints formed only by historical processes, queuing order, or default execution habits.

[0107] For data dependencies, if the output data of node v_i is an indispensable prerequisite for node v_j to form a valid input, such as the entity disambiguation result, parameter value, or structure parsing result generated by v_i that must be read by v_j, then a strong data dependency edge is established from v_i to v_j. v_j must not enter the Ready set as long as the output has not been formed. If v_j uses an independent input that has been frozen in step S201 and does not actually depend on the runtime output of v_i, then a strong data dependency should not be automatically assumed to exist simply because v_i precedes v_j in the original order.

[0108] For state dependencies, M2 compares the read_set and write_set of two nodes. If v_i.write_set intersects with v_j.read_set or v_j.write_set, and the intersecting object is a shared mutable state, then a strong state dependency edge is established. If the shared object has already been transformed into a read-only snapshot, copy-on-write page, or versioned isolated object in step S201, then it can be further determined whether the state dependency can be resolved. In this way, a true read-write conflict is distinguished from the case of accessing only the same logical object but reading different immutable versions.

[0109] For evidence dependencies, if v_i is responsible for generating, filtering, or verifying the evidence necessary for v_j, and v_j can only determine its evidence set after v_i has completed its work, then a strong evidence dependency edge is established. If both nodes use frozen and independent evidence_snapshots, then there is no sequential relationship between them due to real-time evidence changes. This process ensures that nodes scheduled in advance will not see evidence sets different from the original order due to early execution.

[0110] For decision dependencies, M2 determines whether a node's result affects the executable condition, branch selection, or final accept / reject result of other nodes based on the global decision function F and the merging method of the node's local results. For conjunction, disjunction, k-of-n threshold, hierarchical gating, or other combined decision types, logic gates, branch gating conditions, and final merging conditions can be recorded as part of the decision dependency. The purpose of decision dependencies is not to require all nodes participating in the same global decision to be sequential, but rather to identify which nodes have insurmountable logical prerequisites.

[0111] like Figure 3 As shown, solid edges are retained as strong dependencies in the scheduling feasibility constraints; dashed weak-order edges indicate a sequential relationship in the original order, but this relationship has not yet been proven to be necessary for the data, state, evidence, or decision. For example... Figure 3 v2 and v3 in the equation can have an original weak order edge, but when they share the same frozen candidate version, the input and evidence are fixed and there is no mutual dependence, the weak order edge can be further proved as a candidate removal edge.

[0112] Each edge records edge_id, source_node, target_node, edge_type, edge_strength, required_output, version_constraint, removal_condition, provenance, confidence, and certificate_id. Provenance indicates whether the dependency originates from explicit workflow, static data flow analysis, rule derivation, model extraction, historical constraints, or conservative completion; confidence indicates the reliability of dependency identification. For dependencies that cannot be reliably resolved, M2 uses a conservative approach to establish strong dependency edges, rather than assuming nodes can be swapped.

[0113] After M2 completes the dependency graph, it performs graph integrity and consistency checks, including node reference closure, candidate version consistency, loop detection, unresolved input checks, edge type validity checks, and compatibility checks with the original execution order. If a loop is found and it cannot be determined whether it is a purely logical confluence loop or a decomposable structure, the relevant nodes are merged into a non-reorderable group; if a node's read / write set is unknown, the source of evidence is uncertain, or the edge source is not sufficiently reliable, the corresponding relationship is treated as a strong dependency. This step corresponds to... Figure 2 M2 in, and for Figure 3 The strong dependency edges, weak order edges, and Ready set computation provide the structural foundation.

[0114] Step S203: Perform exchangeability analysis to generate exchange certificates and remove certificates with weak order edges.

[0115] The commutativity analysis module M3 analyzes node pairs or groups that do not have strong ancestor-descendant dependencies. Commutativity does not simply mean that two nodes are not directly connected in the topology graph, but requires that changing their relative execution order in the current frozen state does not change the valid input that any node can observe, does not generate unacceptable shared state conflicts, and does not change the interpretation of local results by the final decision function.

[0116] Specifically, for the nodes v_i and v_j to be analyzed, M3 first checks whether they are bound to the same candidate_version_id. If they are bound to different candidate versions, they are in different frozen states and do not participate in the same decision equivalence scheduling. Secondly, it checks whether input_snapshot_id and evidence_snapshot_id are both fixed, and confirms that the execution of v_i will not regenerate or modify the input or evidence of v_j, and the execution of v_j will not regenerate or modify the input or evidence of v_i.

[0117] Next, the read and write sets are checked. If v_i.write_set conflicts with v_j.read_set or v_j.write_set, or if v_j.write_set conflicts with v_i.read_set, swapping is generally not allowed. Swap considerations can only proceed if the conflicting objects use read-only versions, copy-on-write, transaction isolation, or other isolation mechanisms that prove the two nodes will not observe each other's intermediate writes. Shared caches, GPU key-value caches, random number states, retrieval sessions, or utility sessions are also treated as shared mutable states and cannot be judged as conflict-free solely based on logical business fields.

[0118] M3 further examines hidden state and randomness. For validators using language models, retrieval systems, random sampling, or stateful tools, two nodes are assigned independent inference contexts, cache handles, random number generator instances, retrieval sessions, and tool sessions, or a write-once copy is created from the same frozen parent snapshot. If a validator cannot declare or prove its hidden state isolation, the corresponding node of that validator must not participate in the order reordering.

[0119] For verification nodes with external side effects, such as those that modify external databases, send messages, change tool session states, or generate irreversible business actions, M3 checks their `side_effect_class`. Reordering is only permitted within a limited scope if the external side effect is delayed until after the final decision, or if the external interface supports `prepare / commit / abort`, idempotent calls, or verifiable compensation mechanisms. Side effects that are not registered, cannot be compensated, or may affect the observations of other verification nodes are directly deemed non-commutable.

[0120] After the above state conditions are met, M3 then checks the decision semantics. The local result type, local decision threshold, validator version, and global rendezvous rule of the exchange node must remain unchanged. If the original order itself changes the definition of the local result through timeout, retry count, early stop rule, or external observable state, the above factors should be included in the frozen state S_f; if freezing or equivalence cannot be proven, an exchange certificate is not issued.

[0121] When all exchangeable conditions are met, M3 generates an `exchange_certificate`. The exchange certificate records at least the node set, `candidate_version_id`, `input_snapshot_id`, `evidence_snapshot_id`, `validator_version`, read / write set summary, state isolation descriptor summary, the allowed exchange validity period, and the supporting documentation. If a weakly ordered edge still exists between nodes, an `edge_removal_certificate` is also generated to prove that the weakly ordered edge can be ignored in this scheduling instance. Both the exchange certificate and the edge removal certificate are bound to `schedule_instance_id` and are not reused across candidate versions.

[0122] like Figure 3 As shown, if v1 is already completed, and neither v2 nor v3 has an incomplete strong predecessor, and the dashed weak order edge between v2 and v3 obtains a valid removal certificate, while both v2 and v3 obtain exchange certificates, then both v2 and v3 can become members of the current Ready set shown in the shaded area. At this point, their original relative order can be changed. If either certificate fails, the dashed edge reverts to an uncrossable constraint in this run, and at least one node must wait.

[0123] Step S204: Prove decision equivalence and choose between the exchangeable scheduling policy and the conservative scheduling policy.

[0124] After M3 completes the commutativity analysis, the equivalence constraint scheduling module M6 performs a decision equivalence constraint check before actually changing the relative order of nodes. Decision equivalence requires that the sample-by-sample results for the same frozen verification state remain consistent, rather than merely guaranteeing that the average accuracy, overall pass rate, or statistical distribution are similar. In other words, for the same candidate, the final acceptance or rejection result must be the same under both the original execution order and the dynamic scheduling order.

[0125] Let the current frozen verification state be S_f, the original execution order be π_0, the candidate dynamic order be π_d, the allowed combination of local results generated by each node under S_f be a, and the final decision function be F. Under the premise that the candidate version, input snapshot, evidence snapshot, validator version, policy version, decision threshold, and the running state affecting the local results can be fixed, for any allowed combination of local results a, if F_{π_d}(a) = F_{π_0}(a), then the candidate dynamic order is considered to satisfy the decision equivalence constraint.

[0126] In engineering implementation, it is not required to exhaustively enumerate all possible combinations of results for all nodes before scheduling. For predefined decision functions such as AND, OR, k-of-n, and hierarchical gating, pre-defined equivalence rules, Boolean decision graphs, or formal solution methods can be used to confirm that allowed swaps will not change F. For complex decision functions that cannot be directly proven by rules, a conservative strategy can be adopted, that is, reordering is only allowed when the proof tool returns a definite equivalent conclusion; returns of unknown, timeout, or version mismatch are all considered as unprovable.

[0127] When at least one exchangeable node group exists, and the relevant exchange certificate, edge removal certificate, and decision equivalence proof are all valid, M6 selects the exchangeable scheduling strategy. This strategy allows the execution order of nodes in the Ready set to be changed according to risk priority without crossing strongly dependent edges. When there are no exchangeable nodes, dependency information is incomplete, decision equivalence cannot be proven, or runtime verification fails, M6 selects the conservative scheduling strategy.

[0128] The conservative scheduling strategy prioritizes restoring the original topological order or the original serial order. For nodes that are clearly independent and do not share any mutable state, parallelism can continue, but unproven cross-order rearrangements are not performed. This forms a scheduling boundary of "optimize if provable, conservative if unprovable," ensuring that risk priority is only used for ordering legally interchangeable nodes and does not have the authority to break dependency constraints or modify decision semantics.

[0129] Step S205: Construct a valid Ready set, estimate the rejection risk, execution resource cost, subsequent release benefit, and prediction confidence level, and calculate the risk priority.

[0130] correspond Figure 4 In S3 and S4, after adopting the exchangeable scheduling strategy, M6 first constructs a valid Ready set Ready_t at each scheduling time t based on the current verification task dependency graph and the set of completed nodes. For a node v_i to enter Ready_t, at least the following conditions must be met: all its strong predecessor nodes have been completed; its candidate_version_id, input_snapshot_id, and evidence_snapshot_id remain consistent with its frozen state; its associated exchange_certificate and edge_removal_certificate are still valid; and the validator isolation descriptor, side effect state, and policy version have not changed.

[0131] For nodes with weakly ordered predecessors, the weakly ordered predecessor is considered to be in a non-blocking Ready state only if the corresponding weakly ordered edge has obtained a valid edge_removal_certificate and the swap instance verification passes. Therefore, Ready_t is not simply "all nodes with zero in-degree", but a set of legally executable nodes obtained after strong dependency constraints, weak edge removal proofs, frozen version verification, and runtime isolation verification.

[0132] The risk and cost estimation modules M4 / M5 estimate the rejection risk R_i for each node v_i in Ready_t. R_i represents the predicted probability that the node will produce a hard rejection, cause the current candidate to enter the rejection direction, or significantly promote the rejection decision. R_i can be estimated based on the historical rejection frequency of similar nodes, validator type, relation type, structural violation frequency, degree of evidence missing, model uncertainty, entity alignment confidence, topological location, and upstream results obtained in this run. Historical statistics are only used for ranking and do not directly replace the actual local validation results.

[0133] Simultaneously, the execution resource cost C_i is estimated. C_i can consist of one or more of the following: expected verification latency, input and output token consumption, GPU runtime, video memory page usage, CPU core time, memory usage, network transmission, retrieval calls, database queries, third-party API fees, and tool execution costs. Different deployment environments can either normalize the above costs into a uniform resource unit or maintain individual costs and assign weights based on resource scarcity.

[0134] Further estimate the subsequent release benefit B_i. B_i represents the future workload that v_i can cancel or no longer initiate once a hard veto sufficient to drive a final decision is generated. B_i considers not only the static number of successor nodes, but also the expected resource cost of successor nodes, the remaining time of the critical path, whether it is currently QUEUED or RUNNING, the percentage already executed, and whether the node is shared by other candidates. For nodes that are already COMPLETED, non-cancellable tasks, or shared tasks still referenced by other candidates, the remaining release benefit for the current candidate is calculated as zero or based on the attributable percentage to avoid overestimating the cancellation benefit.

[0135] M4 / M5 also provides a prediction confidence level Q_i, which represents the reliability of the estimates of R_i, C_i, and B_i. If a certain type of node has insufficient historical samples, significant changes in runtime load, or large fluctuations in external API latency, then Q_i is reduced. For nodes with confidence levels below a threshold, a risk lower bound, a cost upper bound, or a direct reduction in their risk priority can be used to prevent unstable predictions from prematurely causing errors in high-cost nodes.

[0136] In one optional implementation, the node risk priority_i is calculated as follows: Priority_i = (R_i × B_i × Q_i) / (C_i + ε), where ε is a positive number to prevent an abnormal ratio caused by zero or extremely low execution resource costs. This formula implies that nodes that are more likely to be rejected early, have a larger subsequent workload that can be released after rejection, a more reliable prediction, and a lower execution cost should be executed first. The ratio of the product of rejection risk, subsequent release benefits, and prediction confidence to the execution resource cost is the core relationship for this type of priority calculation.

[0137] When multiple nodes have the same Priority_i or a difference below a preset threshold, secondary sorting factors that do not change the decision equivalence constraints can be used. These factors include the remaining length of the critical path, the estimated completion time, cache hit rate, whether the node can form the same GPU micro-batch with other nodes, and the original topology order. Retaining the original topology order as the final tie rule can improve the repeatability of scheduling results without affecting resource gains.

[0138] Combination Figure 3 Further explanation: When v2 and v3 are both in Ready_t, M4 / M5 calculate their R, C, B, and Q values ​​respectively. If v3 has a higher priority than v2, the dynamic order can execute v3 first and then v2, meaning v3 is allowed to skip a step. Figure 3 The path contains removable weakly ordered edges; if v2 has higher priority, then v2 is executed first. In either case, v4 still waits for its strong predecessor v2 to complete, v5 still waits for its strong predecessor v3 to complete, and v6 still waits for the strong dependency conditions for entering its path to be met; therefore, risk priority is not violated. Figure 3 The real-line dependency structure.

[0139] Step S206: Generate a scheduling instruction set and dynamically schedule each verification node to execute it under the decision equivalence constraint.

[0140] The equivalence constraint scheduling module M6 selects the current target verification node based on Ready_t and Priority_i obtained in step S205 and generates a scheduling instruction. The scheduling instruction includes at least schedule_instance_id, node_id, candidate_version_id, input_snapshot_id, evidence_snapshot_id, validator_version, resource budget, execution isolation descriptor, allowed external resource range, and a result write-back token. The result write-back token is bound to the current scheduling instance and the cancellation epoch for subsequent identification of late results.

[0141] Before a node moves from READY to QUEUED or RUNNING, M6 performs a runtime review again. The review includes at least the following: frozen candidate versions remain unchanged; input and evidence snapshots are readable; exchange certificates have not expired; weak edge removal certificates are still valid; validator versions and container digests remain unchanged; read / write set declarations remain unchanged; and external side-effect control states meet the exchange conditions. If any review fails, the current cross-order scheduling is not executed; instead, M10 restores the corresponding weak-order edges to strong constraints or switches the entire node to conservative scheduling.

[0142] The verification execution and aggregation module M7 invokes the corresponding validator in an independent execution context according to the scheduling instructions. For stateless validators, execution is performed directly with frozen inputs and evidence; for read-only snapshot state validators, only the current frozen state can be read; for isolated variable validators, an independent writable state or a copy-on-write state is assigned to the node. Nodes must not modify the frozen inputs, evidence snapshots, or global decision functions of other nodes.

[0143] After a node completes execution, M7 writes the local result to the current part assignment α_t, along with the node state, completion time, actual resource consumption, validator output digest, and result hash. If the local result is successful, nodes in its strong successor list that have met all predecessor conditions are released normally; if the local result is a hard rejection, the process proceeds to step S207 to perform a decision deterministic check, instead of unconditionally and immediately canceling all incomplete tasks.

[0144] While the final decision is pending, for each node affecting the decision that is completed, M6 recalculates the strong dependency satisfaction conditions and the legal Ready set, while M4 / M5, based on the latest runtime information, re-estimates R, C, B, and Q, and recalculates Priority. Therefore, the dynamic scheduling order is not a one-time static sort, but rather gradually forms as nodes complete, risk information is updated, resource load changes, and cancelable workloads change.

[0145] When a conservative scheduling strategy is adopted, a scheduling instruction set can still be generated, but node selection follows the original topological order or a conservative serial order. Risk priority is only used as auxiliary information that does not affect the original sequential constraints and is not used to cross weak edges. In this way, even if the system degenerates to conservative mode, the verification execution, merging, auditing, and late result isolation mechanisms can still continue to function.

[0146] Step S207: When a node outputs a hard rejection, update the partial assignment and determine whether the final decision has entered the absorption state.

[0147] correspond Figure 4 S6 and Figure 5In the first two processing blocks, when any validator node outputs a hard rejection, M7 first writes the hard rejection result, along with the corresponding node_id, candidate_version_id, and result_hash, into the current part assignment α_t. A hard rejection means explicitly determining that the local condition is not met under the current validator rules, rather than based on a high risk prediction value, low confidence level, or validator execution anomaly. Risk prediction only affects the order of nodes and does not directly constitute the final rejection basis.

[0148] Then, the decision determinism checker is invoked to determine whether the global decision has entered the absorption state. The absorption state means that, given that the current partial assignment α_t is fixed, the output of the final decision function F remains the same result y, regardless of the allowed results obtained by the unresolved nodes. Formally, for any possible combination of results z of the unresolved node set U_t, if F(α_t∪z)=y, then the final decision has been determined to be y.

[0149] For global AND-type non-compensatory decisions, the rejection condition is met as long as any necessary node outputs a hard rejection, because subsequent passes or rejections by other nodes cannot restore the global result to acceptance. For OR-type decisions, passing any necessary branch can put the acceptance direction into the absorption state, while a single branch rejection usually does not immediately determine rejection; rejection is only determined when all branches that could still produce acceptance are rejected.

[0150] For k-of-n threshold decisions, if the number of currently passed decisions reaches k, the decision is accepted; if the number of currently failed decisions exceeds nk, the decision is rejected. For hierarchical gating, conditional branching, or other complex decision functions, it is possible to check whether unresolved variables might still change the final result using rule templates, Boolean decision graphs, finite result enumeration, or SAT / SMT solutions. If the check result is UNKNOWN, a timeout occurs, or the decision rule version is inconsistent, the absorption state must not be declared.

[0151] Before the final decision enters the absorption state, the system must not cancel nodes that may still affect the final decision simply because of a hard rejection. At this point, only branch-exclusive nodes that have been independently proven to belong only to the failed branch and whose output will not change other valid branches or the final decision can be canceled; nodes that cannot form a proof of local independence continue execution. This process avoids applying simple early stopping errors to OR, threshold, or complex gating decisions.

[0152] When the decision determinism checker confirms that the final decision has entered the accept or reject absorption state, a decision_absorbed record is formed, which includes at least the current partial assignment, decision function version, absorption direction, proof type, proof hash, the node that first made the decision deterministic, and the current cancellation epoch. Then, step S208 is taken to calculate the secure cancellation closure.

[0153] Step S208: Calculate the safe cancellation closure based on the verification task dependency graph, decision function, and shared reference relationships.

[0154] The dependency propagation cancellation module M8 calculates the decision_absorbed record as the trigger condition. Figure 5 The term "decision-irrelevant nodes and failed branch exclusive closures" is used. The cancellation closure is not simply a set of all incomplete nodes, but only includes nodes whose continued execution can be proven not to change the current final decision, and whose cancellation will not disrupt other candidates, other shared tasks, or necessary audit processes.

[0155] Specifically, M8 first identifies decision-irrelevant nodes from the currently incomplete nodes, that is, nodes whose local results will not change the output of F regardless of the current partial assignment and the determined decision direction; secondly, it identifies successor nodes that only serve branches that have failed; and thirdly, it analyzes whether canceling a node will destroy the shared results that the nodes that still need to be executed depend on, in conjunction with the verification task dependency graph.

[0156] For verification tasks shared by multiple candidate objects, multiple scheduling instances, or multiple valid branches, M8 reads the shared reference count, `reference_count`. If the current candidate is only one of the users, the cancellation operation only unsubscribes from or removes the reference of the current candidate, without directly terminating the underlying shared task; only when `reference_count` drops to zero and there are no other valid users does the underlying task enter the cancelable set. This avoids accidentally affecting other tasks that still need the verification result in order to release resources for the current candidate.

[0157] M8 also differentiates the cancellation handling method based on node_status. For nodes that are still in the WAITING, READY, or QUEUED state and have not yet actually consumed verification resources, they are directly marked as CANCELLED or SKIPPED and removed from the scheduling queue; for nodes that are already RUNNING and whose execution environment supports safe cancellation, a cancellation token carrying schedule_instance_id and cancel_epoch is sent.

[0158] For nodes that have already invoked external APIs, databases, retrieval services, or tools and cannot be interrupted immediately, the assumption that external execution has stopped is not enforced. Instead, the result write-back token is revoked, ensuring that even if the task continues to run, its returned result cannot participate in the current final decision. For external services that support idempotent cancellation or transaction abort, corresponding cancellation or abort requests can be sent; for services that do not support cancellation, result isolation is maintained until the task terminates naturally.

[0159] After the cancellation closure is determined, M8 generates a CancellationRecord, which records the cancellation reason, the direction of the decision absorption, the first decisive node, the set of nodes to be cancelled, the set of shared nodes to be dereferenced, the set of nodes that sent the cancellation token, the set of nodes that cannot be cancelled immediately but whose write permissions have been revoked, and the cancel_epoch. This record is passed to M9 for auditing and used by M10 as a basis for determining which tasks have failed during anomaly recovery.

[0160] Step S209: Isolate late results and safely release the computing, cache, network, and external access resources occupied by the canceled node.

[0161] correspond Figure 5 The "Reject Late Result Write" option on the right and the resource release handling below, after the final decision enters the absorption state and cancellation is executed, M7 performs a write eligibility check on any subsequently returned verification results. The returned result carries at least candidate_version_id, schedule_instance_id, evidence_snapshot_id, node_id, and cancel_epoch; optionally, it also carries input_snapshot_id, validator_version, and result_hash.

[0162] If the candidate version, scheduling instance, evidence snapshot, or input snapshot to which the returned result belongs is inconsistent with the current freeze state, or its cancel_epoch is earlier than the current cancellation epoch, or the corresponding node_id is already in the cancellation closure and the write-back token has been revoked, then the result is only written to the audit isolation zone. It may not update the current part of the assignment, may not reopen the cancelled successor node, and may not change the final judgment that has been determined.

[0163] For nodes that are canceled or terminated naturally, the corresponding resources are released after confirming that there are no longer any valid references that still require their exclusive resources. Resources include, but are not limited to, GPU batch locations, exclusive video memory pages, node-level key-value caches, token budgets, CPU threads or coroutines, network connections, retrieval sessions, utility slots, database connections, and external API quotas. For shared cache pages, shared retrieval results, or shared execution instances, only the reference count of the current candidate is decremented; they are not physically released if there are still other valid references.

[0164] M8 / M7 records the actual amount of resources released, the percentage already executed before cancellation, and the time consumed during cancellation, which are then used by M4 / M5 to update the resource cost and subsequent release benefit model. In this way, risk-priority scheduling can use the actual cancellation effect for subsequent estimations, but model updates only affect future scheduling priorities and do not reverse-modify the local verification results and final decision already formed.

[0165] Step S210: Based on the necessary local verification results, form a final decision to accept or reject, which is identical to the original execution order.

[0166] If all necessary verification nodes affecting the final acceptance decision are completed and meet the pass conditions, and the decision function F is determined to be ACCEPT under the current partial assignment, then M7 forms the acceptance decision. For AND-type decisions, this is usually manifested as all necessary nodes passing; for OR, k-of-n, or hierarchical gating-type decisions, the acceptance condition is determined according to the frozen version of the decision function.

[0167] If any hard veto, combined with the current decision rule, causes the global decision to enter a rejection absorption state, a rejection decision is formed. The basis for a rejection decision comes from the actual local verification results and the proof of decision certainty, rather than scheduling priority prediction. Risk priority only determines which legitimate Ready node is verified first; therefore, even if the risk model prediction is incorrect, it will at most affect resource efficiency and decision formation time, without changing the final decision rule.

[0168] The final decision record is associated with at least the candidate_version_id, schedule_instance_id, decision_rule_version, the set of used local verification results, the absorbed state proof or necessary pass proof, the dynamic actual execution order, and the original execution order identifier. This proves that the final decision applies to the same candidate object frozen in step S201, rather than other objects that have changed during the verification process.

[0169] Because dynamic scheduling always satisfies strong dependency edges, the same frozen candidate version and snapshot are always used for exchange nodes, local decision rules and global convergence rules remain unchanged, and decision-irrelevant nodes are only canceled after the decision is absorbed, the final decision formed by the dynamic execution order is equivalent to the final decision formed by the original execution order on a sample-by-sample basis.

[0170] Step S211: Record the complete audit trail and verify the equivalence of the judgment and the resource benefits by replaying the footage.

[0171] The auditing and replay module M9 continuously records essential audit information throughout the entire lifecycle of the scheduling instance. Audit information includes at least the original execution order, the actual dynamic execution order, the Ready set at each scheduling moment, node priority, the reason for a node being selected or not selected, strong dependency edges and weak order edges that were removed, certificate exchanges, edge certificate removal, and certificate versions.

[0172] M9 also records candidate_version_id, input_snapshot_id, evidence_snapshot_id, validator and policy version, node start and end time, actual resource consumption (Token / GPU / CPU / API, etc.), partial verification results, partial assignment changes, decision determinism check results, decision_absorbed proof, canceled closure, cancel_epoch, late result rejection records, and actual resource release.

[0173] To support audit replay, key snapshots and certificates can be saved as content-addressable objects or records with immutable version numbers, enabling the replay procedure to re-obtain candidate, input, evidence, and decision rules consistent with the original scheduling instance. In one implementation, M9 replays the necessary verification nodes in the original execution order π_0 and compares the replayed final decision with the final decision obtained in the dynamic order π_d sample by sample.

[0174] If the replay results are consistent, record equivalence_pass; if there is a discrepancy, record equivalence_fail, and save the first inconsistent node, related certificate, snapshot and policy version. At the same time, add the corresponding exchange rule, node type or policy version to the risk list, and M10 will prohibit the continued use of the same reordering conditions in subsequent scheduling until the verification is completed again or the policy is upgraded.

[0175] The audit log serves both to prove that the dynamic scheduling did not alter the decision and to calculate scheduling benefits, such as the reduction in average number of verification nodes, token consumption, GPU time, video memory usage, number of external API calls, and decision latency compared to the original order. Resource benefit metrics and decision equivalence results are recorded separately; resource savings are only counted as valid optimization benefits when the equivalence verification passes.

[0176] Step S212: Continuously review security conditions during operation, and switch to conservative scheduling via the degradation and rollback interface when it is impossible to prove decision equivalence or security dependency.

[0177] The degradation and rollback interface M10 continuously receives status information from M2, M3, M6, M7, and M9. M10 triggers a risk degradation mechanism when the following situations occur: incomplete dependencies, dependency graph loops that cannot be safely handled, changes to candidate versions or snapshots, inconsistencies between validator read / write sets and registered information, inability to isolate shared mutable hidden states, unregistered external side effects, expired exchange or edge removal certificates, changes to decision rule versions, unavailable audit links, or runtime anomalies.

[0178] If the anomaly only affects a single weak-order edge or a group of commutative nodes, a local degradation can be performed: the certificate for the corresponding edge is revoked or swapped, the relevant weak edge is restored to a strong constraint in the current scheduling instance, and the Ready set is recalculated. Affected nodes that have not yet started return to the waiting state. Nodes that have already started with a valid old certificate can complete their execution while their execution results remain bound to the same frozen state and do not cause conflicts, but they must not use this as a basis to start new, unproven cross-order nodes.

[0179] If the local boundary of the anomaly cannot be determined, or if the decision equivalence basis such as candidate versions, input evidence snapshots, or decision functions changes, then an overall downgrade is performed, new dynamic cross-order scheduling is stopped, and verification continues according to the original topological order or conservative serial order. Local results that have been completed and can be proven to still apply to the same frozen state can be retained; results that cannot be proven to still be applicable are marked as unusable for the current final decision, and the corresponding nodes are re-executed according to the actual implementation.

[0180] The rollback primarily targets the execution plans of the scheduling state, the Ready set, and unexecuted nodes, and does not involve reversing the modification of already established valid fact verification results. For issued external side effects, if they have transaction abort or compensation capabilities, they are handled according to the registered side effect control protocol; for irreversible external actions, they should be marked as non-reorderable side effects and given a conservative order in subsequent scheduling to avoid mistakenly treating unrecoverable external state changes as safe for exchange.

[0181] After a downgrade, M9 continues to record the downgrade reason, triggering node, invalidation certificate, scheduling order before and after the downgrade, and any partial results that were re-executed or retained. The final decision is still formed according to the same freeze decision rule. Therefore, the role of M10 is to limit the scope of scheduling optimization rather than change the decision criteria, so that the system will proactively give up some or all optimization benefits when it cannot prove safety, thus ensuring that the final decision remains equivalent to the original execution order.

[0182] Through the above steps S201 to S212, Figure 2 The main processing chain M1 to M7 and the auxiliary modules M8 to M10 form a closed loop: M1 fixes the input basis for the equivalence comparison of the decision; M2 and M3 limit the range of execution order that can be changed; M4 / M5 calculate risk and reward only within the legal Ready set; M6 generates the actual scheduling order under equivalence constraints; M7 performs verification and forms partial assignment and final decision; M8 safely cancels after decision absorption; M9 saves the equivalence proof and replay basis; M10 degrades when the proof condition fails. Figure 3 An example graph structure is given for which commutable nodes are added to the Ready set. Figure 4 The main process of the above closed loop is given. Figure 5 The safety cancellation boundary after a hard veto is further defined. Therefore, this embodiment does not simply reorder verification tasks according to risk scores, but implements risk-priority scheduling under the premise of "freezing consistency, security of dependency, exchangeability and provability, and equivalence of final decision".

[0183] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0184] This invention also provides a decision equivalence risk priority audit scheduling device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated for details already described. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0185] Figure 6According to one embodiment of the present invention, a decision equivalence risk priority audit scheduling device includes:

[0186] The response module 301 is used to determine the verification task dependency graph in response to the multi-hop generation verification task start signal, wherein the verification task dependency graph includes multiple verification nodes and the dependency relationships between the verification nodes.

[0187] The determination module 302 is used to determine an adjustment strategy based on the verification task dependency graph. The adjustment strategy is used to adjust the execution order of the verification nodes from the original execution order to the dynamic scheduling order while maintaining equivalence with the final decision of the original execution order. The adjustment strategy includes: a swappable scheduling strategy and a conservative scheduling strategy.

[0188] The generation module 303 is used to generate a scheduling instruction set in response to the adjustment strategy. The scheduling instruction set is used to schedule each of the verification nodes to perform verification according to the dynamic scheduling order, and to form a final decision that is the same as the original execution order based on the local verification results of each of the verification nodes.

[0189] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0190] According to one embodiment of the present invention, an electronic device is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the above-described decision equivalence risk priority audit scheduling method during runtime.

[0191] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0192] Step S1: In response to the multi-hop generation verification task start signal, determine the verification task dependency graph, wherein the verification task dependency graph includes multiple verification nodes and the dependency relationships between each verification node;

[0193] Step S2: Based on the verification task dependency graph, determine the adjustment strategy. The adjustment strategy is used to adjust the execution order of the verification nodes from the original execution order to the dynamic scheduling order while maintaining equivalence with the final decision of the original execution order. The adjustment strategy includes: exchangeable scheduling strategy and conservative scheduling strategy.

[0194] Step S3: In response to the adjustment strategy, a scheduling instruction set is generated. The scheduling instruction set is used to schedule each verification node to perform verification according to the dynamic scheduling order, and to form a final decision that is the same as the original execution order based on the local verification results of each verification node.

[0195] According to one embodiment of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the storage medium is located to execute the above-described decision equivalence risk priority audit scheduling method.

[0196] Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:

[0197] Step S1: In response to the multi-hop generation verification task start signal, determine the verification task dependency graph, wherein the verification task dependency graph includes multiple verification nodes and the dependency relationships between each verification node;

[0198] Step S2: Based on the verification task dependency graph, determine the adjustment strategy. The adjustment strategy is used to adjust the execution order of the verification nodes from the original execution order to the dynamic scheduling order while maintaining equivalence with the final decision of the original execution order. The adjustment strategy includes: exchangeable scheduling strategy and conservative scheduling strategy.

[0199] Step S3: In response to the adjustment strategy, a scheduling instruction set is generated. The scheduling instruction set is used to schedule each verification node to perform verification according to the dynamic scheduling order, and to form a final decision that is the same as the original execution order based on the local verification results of each verification node.

[0200] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0201] According to one embodiment of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the above-described decision equivalence risk priority audit scheduling method.

[0202] Optionally, in this embodiment, the above-mentioned computer program product can be configured as a computer program that performs the following steps:

[0203] Step S1: In response to the multi-hop generation verification task start signal, determine the verification task dependency graph, wherein the verification task dependency graph includes multiple verification nodes and the dependency relationships between each verification node;

[0204] Step S2: Based on the verification task dependency graph, determine the adjustment strategy. The adjustment strategy is used to adjust the execution order of the verification nodes from the original execution order to the dynamic scheduling order while maintaining equivalence with the final decision of the original execution order. The adjustment strategy includes: exchangeable scheduling strategy and conservative scheduling strategy.

[0205] Step S3: In response to the adjustment strategy, a scheduling instruction set is generated. The scheduling instruction set is used to schedule each verification node to perform verification according to the dynamic scheduling order, and to form a final decision that is the same as the original execution order based on the local verification results of each verification node.

[0206] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0207] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0208] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0209] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0210] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0211] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0212] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for scheduling audits based on judgment equivalence risk, characterized in that, include: In response to a multi-hop generation verification task start signal, a verification task dependency graph is determined, wherein the verification task dependency graph includes multiple verification nodes and the dependency relationships between the verification nodes; Based on the verification task dependency graph, an adjustment strategy is determined. The adjustment strategy is used to adjust the execution order of the verification nodes from the original execution order to the dynamic scheduling order while maintaining equivalence with the final decision of the original execution order. The adjustment strategy includes: a swappable scheduling strategy and a conservative scheduling strategy. In response to the adjustment strategy, a scheduling instruction set is generated, which is used to schedule each of the verification nodes to perform verification according to the dynamic scheduling order, and to form a final decision that is the same as the original execution order based on the local verification results of each of the verification nodes.

2. The judgment equivalence risk priority audit scheduling method according to claim 1, characterized in that, Determining the verification task dependency graph includes: Obtain the object to be verified, and freeze the candidate versions of the object to be verified, the input snapshots of each verification node, and the evidence snapshots; Each verification node is decomposed to determine its data dependency, state dependency, evidence dependency, and judgment dependency. Based on the data dependency, the state dependency, the evidence dependency, and the decision dependency, the verification task dependency graph is constructed.

3. The judgment equivalence risk priority audit scheduling method according to claim 2, characterized in that, Based on the verification task dependency graph, the adjustment strategy is determined, including: Exchangeability analysis is performed on each of the aforementioned verification nodes to determine exchangeable verification nodes. The exchangeable verification nodes are those that simultaneously meet the following conditions: no ancestor-descendant dependency relationship, bound to the same frozen candidate version, input snapshot and evidence snapshot are consistent, read and write sets are conflict-free, there is no sharing of variable hidden states, and there are no external side effects that affect each other. Based on the exchangeable verification node, the exchangeable scheduling strategy is determined; When there is no exchangeable verification node, or it cannot be proven that the exchangeable verification node satisfies the decision equivalence constraint, the conservative scheduling strategy is determined.

4. The judgment equivalence risk priority audit scheduling method according to claim 3, characterized in that, Determining the adjustment strategy based on the verification task dependency graph further includes: Determine the current set of executable nodes; Under the exchangeable scheduling policy, the scheduling attribute information of each executable node is estimated, wherein the scheduling attribute information includes at least one of the following: rejection risk, execution resource cost, subsequent release benefit, and prediction confidence. Based on the scheduling attribute information, the scheduling priority of each executable node is determined; The dynamic scheduling order is determined based on the scheduling priority.

5. The judgment equivalence risk priority audit scheduling method according to claim 4, characterized in that, Estimating the scheduling attribute information of each of the executable nodes includes: The veto risk is determined based on historical veto records, verification node types, evidence characteristics, and topological locations. The execution resource cost is determined based on the expected latency, token consumption, GPU usage, video memory usage, CPU usage, network cost, and external API call cost. The subsequent release revenue is determined based on the estimated workload of the subsequent verification node that can be canceled after the verification node generates a veto. The prediction confidence level is determined based on the reliability of the estimated rejection risk and the execution resource cost.

6. The judgment equivalence risk priority audit scheduling method according to claim 5, characterized in that, Based on the scheduling attribute information, the scheduling priority of each executable node is determined, including: The scheduling priority is determined based on the ratio of the product of the veto risk, the subsequent release benefit, and the predicted confidence level to the execution resource cost. In response to the scheduling priority, a target verification node is selected from the set of currently executable nodes; Add the target verification node to the dynamic scheduling order.

7. The judgment equivalence risk priority audit scheduling method according to claim 1, characterized in that, In response to the adjustment strategy, after generating the scheduling instruction set, the method further includes: In response to a hard rejection generated by any of the verification nodes, update the current partial assignment; Based on the current partial assignment, a judgment determinism check is performed to determine the final judgment status; In response to the final decision status being "decision determined", a cancellation closure is determined according to the verification task dependency graph, and the verification node to be cancelled in the cancellation closure is cancelled. The late verification result will not be included in the final judgment.

8. The judgment equivalence risk priority audit scheduling method according to claim 7, characterized in that, The cancellation closure is determined based on the verification task dependency graph, and the verification node to be cancelled in the cancellation closure is cancelled, including: The cancellation closure is calculated based on the verification task dependency graph, the decision function, the node purpose of each verification node, and the shared reference count. Send a cancellation token to the pending verification node that is running and supports cancellation; New, unnecessary verification nodes are prohibited from joining the queue; For external tasks that do not support immediate cancellation, revoke their write permissions for results and perform version verification and snapshot verification on the returned results.

9. A decision equivalence risk priority audit scheduling device, characterized in that, include: A response module is used to respond to a multi-hop generation verification task start signal and determine a verification task dependency graph, wherein the verification task dependency graph includes multiple verification nodes and the dependency relationships between the verification nodes. The determination module is used to determine an adjustment strategy based on the verification task dependency graph. The adjustment strategy is used to adjust the execution order of the verification nodes from the original execution order to the dynamic scheduling order while maintaining equivalence with the final decision of the original execution order. The adjustment strategy includes: a swappable scheduling strategy and a conservative scheduling strategy. A generation module is used to generate a scheduling instruction set in response to the adjustment strategy. The scheduling instruction set is used to schedule each of the verification nodes to perform verification according to the dynamic scheduling order, and to form a final decision that is the same as the original execution order based on the local verification results of each of the verification nodes.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, the device on which the storage medium is located executes the decision equivalence risk priority audit scheduling method of any one of claims 1 to 8.

Images