Natural language generation-based automatic scriptwriting method and system for a mock human drama

Abstract

The application discloses a natural language generation-based automatic human-like play compiling method and system, and relates to the technical field of task compilation. The method comprises the following steps: when receiving an input natural language description, performing semantic analysis on the natural language description to obtain a task sequence for human-like play generation, constructing a task dependency mapping table based on the task sequence, labeling input data identifiers and output data identifiers for task nodes corresponding to each task sequence in the task dependency mapping table, and monitoring the execution state of each task node; when detecting that any task node fails to execute, triggering a corresponding influence propagation calculation process, and performing recursive propagation analysis on an output data identifier set to obtain minimum re-planning subgraph execution consistency verification, generate a corresponding node execution marker set, and perform local re-planning and replacement on the minimum re-planning subgraph, thereby solving the problem that the execution state coordination between a repaired subtask and a non-replanned subtask in the prior art is poor.

Description

Technical Field

[0001] This invention relates to the field of task scheduling technology, and in particular to a method and system for automatic scheduling of simulated live-action dramas based on natural language generation. Background Technology

[0002] In recent years, with the continuous development of artificial intelligence (AI) technologies such as natural language processing, computer vision, and speech synthesis, it has gradually become possible to automatically generate visualized dynamic content from text stories. This process involves understanding the intent of the input natural language, semantically parsing the user input, extracting the main objective, constraints, and implicit needs, and recursively decomposing them into a directed acyclic graph with data and control dependencies through hierarchical task planning. Subsequently, for each atomic subtask, matching external tools such as APIs and functions are retrieved, and precise parameters matching the input pattern are generated based on the context. The execution engine schedules these tool calls in topological order, while maintaining working memory to store intermediate results and triggering local replanning based on the current state when encountering call failures, timeouts, or constraint conflicts. Finally, all successfully executed outputs are aligned with the original objective, and a natural language response containing an execution summary, key data, and optional subsequent actions is generated through language model aggregation.

[0003] The current task orchestration adopts a planning-execution architecture, specifically: the planning module generates an initial directed acyclic task graph based on natural language; the execution engine schedules tool calls according to topological order, such as character skeletal animation generation, lip-sync speech synthesis, and camera trajectory planning, and maintains working memory to store intermediate results; when a subtask fails, times out, or has a constraint conflict, a local replanning based on the current state is triggered. However, this architecture still has the following shortcomings in the local replanning process: when a subtask fails and triggers local replanning, it only corrects the local dependencies between the failed task and its direct successor, failing to assess the impact of the failure on other branches in the task graph that are not directly successors but have implicit data relationships. This leads to data inconsistencies or execution order conflicts between the repaired subgraph and the unreplanned part. During the local replanning process, there is a problem of poor execution state coordination between the repaired subtask and the unreplanned subtask. Summary of the Invention

[0004] To address the technical problems existing in the prior art, embodiments of the present invention provide a method and system for automatically arranging simulated live-action dramas based on natural language generation. The technical solution is as follows: On the one hand, a method for automatic arrangement of simulated live-action dramas based on natural language generation is provided, which includes: S1: When the input natural language description is received, semantic parsing is performed on the natural language description to obtain the task sequence for generating the simulated live-action drama. A task dependency mapping table is constructed based on the task sequence, and input data identifiers and output data identifiers are marked for the task nodes corresponding to each task sequence in the task dependency mapping table.

[0005] S2: Based on the task dependency mapping table, monitor the execution status of each task node. When any task node fails to execute, trigger the corresponding impact propagation calculation process to determine the corresponding output data identifier set.

[0006] S3: Perform recursive propagation analysis on the output data identifier set to obtain the minimum replanning subgraph, perform consistency verification, generate the corresponding node execution tag set, and perform local replanning and replacement on the minimum replanning subgraph to update the scheduling results and execution status of the corresponding task nodes.

[0007] On the other hand, a natural language-based automatic scheduling system for simulated live-action dramas is provided, which includes: The semantic parsing and labeling module is used to perform semantic parsing on the natural language description received as input to obtain the task sequence for generating the simulated live-action drama. Based on the task sequence, a task dependency mapping table is constructed, and input data identifiers and output data identifiers are labeled for the task nodes corresponding to each task sequence in the task dependency mapping table.

[0008] The impact propagation analysis module is used to monitor the execution status of each task node based on the task dependency mapping table. When any task node fails to execute, the corresponding impact propagation calculation process is triggered to determine the corresponding set of output data identifiers.

[0009] The local replanning and replacement module is used to perform recursive propagation analysis on the output data identifier set to obtain the minimum replanning subgraph, perform consistency verification, generate the corresponding node execution tag set, and perform local replanning and replacement on the minimum replanning subgraph to update the scheduling results and execution status of the corresponding task nodes.

[0010] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following: 1. By parsing natural language descriptions into task sequences with data dependencies and introducing a task dependency mapping table and an influence propagation calculation mechanism, the input natural language descriptions are first semantically parsed to obtain the task sequences used to generate the simulated live-action drama. A task dependency mapping table is then constructed, labeling each task node with input and output data identifiers. During execution, the status of each task node is monitored in real time. When a task node fails, the entire orchestration process is not immediately halted or a global replanning is performed. Instead, influence propagation calculation is triggered to determine the set of output data identifiers for the failed node. Recursive propagation analysis of this set yields the minimum subgraph requiring replanning, followed by consistency checks and local replanning replacement. This approach, centered on the failed node and using propagation along data dependencies to define replanning, can more effectively address local failure issues. In real-world simulated live-action drama generation scenarios, the number of task nodes is large and the dependencies are complex. Re-executing all tasks every time a failure occurs would waste computational resources and increase response latency. By dynamically identifying the affected area and constructing a minimum replanning subgraph, the orchestration process can repair necessary subgraph regions and retain the execution results of unaffected nodes when faced with abnormal execution of some tasks. This improves the continuity and resource utilization efficiency of the entire orchestration process and better adapts to the real-time and stability requirements of automatic orchestration for live-action dramas.

[0011] 2. In the semantic parsing stage, not only are semantic elements such as plot theme, character identity, scene environment, event goals, and time sequence extracted, but the dependencies between different generation requirements are further identified. Semantic fragments with independent execution goals are divided into task nodes. The process of constructing a task dependency mapping table introduces mechanisms such as data production recording, input / output data identifier matching, shared data dependency relationships, and derived data identifier combination. Each task node is assigned an identifier, and the production task node and version number of its output data identifier are recorded. When the input data identifier of a subsequent task node matches an existing output data identifier, a directed dependency relationship is established and the version number is recorded. If multiple task nodes depend on the same output data identifier, a shared data dependency is formed. If an input data identifier is composed of multiple output data identifiers, it is recorded as a derived data identifier and its source. This multi-dimensional dependency mapping table can more precisely describe data versions, shared resources, and derived relationships. In the arrangement of simulated live-action dramas, there are often complex data reuse and combination relationships between different task nodes. For example, multiple downstream tasks share the same character output, or a task needs to integrate the outputs of multiple upstream tasks. The mapping table above enables subsequent failure propagation analysis to identify affected nodes in shared and derived dependencies, avoiding misjudgments or omissions in the propagation scope due to insufficient description of dependencies, and providing a reliable data foundation for local replanning.

[0012] 3. After obtaining the initial propagation queue, this invention performs recursive propagation analysis to gradually expand the set of affected nodes. Task nodes in the initial propagation queue are added to the set of affected nodes as the current node. Then, based on the task dependency mapping table, all downstream task nodes that use the current node's output data identifier as their input data identifier are searched, and version consistency is determined for each downstream task node. This approach considers not only direct dependencies but also propagates the data layer by layer along the data flow, while pruning propagation branches based on both version consistency and execution status. In the automatic staging of simulated live-action dramas, the impact of failure often spreads downstream along the dependency chain, but not all downstream nodes require replanning. For example, although a downstream node depends on the output of a failed node, if that node has already executed successfully and its output is no longer used by subsequent unexecuted nodes, then even if the upstream fails, the result of that node can still be retained. This invention, through recursive propagation, can dynamically determine the actual set of affected nodes, avoiding excessive expansion of the replanning scope and preventing the omission of indirectly affected nodes. It is more in line with the dynamic execution environment and helps to achieve a better balance between staging efficiency and correctness. Attached Figure Description

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

[0014] Figure 1 A flowchart illustrating the automatic arrangement method for simulated live-action dramas based on natural language generation provided in this embodiment of the invention; Figure 2 The flowchart corresponding to the semantic parsing provided in the embodiments of the present invention; Figure 3 The flowchart corresponding to the impact propagation calculation provided in the embodiments of the present invention; Figure 4 The flowchart corresponding to the recursive propagation analysis provided in the embodiments of the present invention; Figure 5 A schematic diagram of the structure of the simulated live-action drama automatic choreography system based on natural language generation provided in an embodiment of the present invention; Figure 6 A comparison chart of accuracy changes during multiple iterations provided in this embodiment of the invention. Detailed Implementation

[0015] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0016] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0017] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0018] This invention provides an automatic arrangement method for simulated live-action dramas based on natural language generation, such as... Figure 1 The flowchart shown is for an automatic staging method for simulated live-action dramas based on natural language generation. The processing flow of this method may include the following steps: S1: When the input natural language description is received, semantic parsing is performed on the natural language description to obtain the task sequence for generating the simulated live-action drama. A task dependency mapping table is constructed based on the task sequence, and input data identifiers and output data identifiers are marked for the task nodes corresponding to each task sequence in the task dependency mapping table.

[0019] S2: Based on the task dependency mapping table, monitor the execution status of each task node. When any task node fails to execute, trigger the corresponding impact propagation calculation process to determine the corresponding output data identifier set.

[0020] S3: Perform recursive propagation analysis on the output data identifier set to obtain the minimum replanning subgraph, perform consistency verification, generate the corresponding node execution tag set, and perform local replanning and replacement on the minimum replanning subgraph to update the scheduling results and execution status of the corresponding task nodes.

[0021] When receiving natural language text input from a user to describe a simulated lifelike storyline, the system first performs semantic parsing on the text, such as... Figure 2 The diagram shown is a flowchart of the semantic parsing process provided in an embodiment of the present invention. The specific process is as follows: First, the received natural language description is segmented into individual word units according to the grammatical rules of Chinese or other natural languages. This operation can be achieved by calling existing natural language processing toolkits, such as Chinese word segmentation tools. After text segmentation, semantic recognition is performed on each word unit to determine its semantic category based on its meaning in the current context. A semantic element classification library is pre-set, which defines categories such as plot theme, character identity, scene environment, event target, and time sequence, and associates a set of typical keywords or semantic templates with each category. When a segmented word matches a keyword or semantic template under a certain category, the word and its corresponding semantic information are extracted as the corresponding semantic element; for example, if the word "prince" appears, it is classified as a character identity element; if the word "forest" appears, it is classified as a scene environment element.

[0022] After extracting semantic elements, the next step is to analyze the directional, logical, and temporal relationships between these elements. A directional relationship refers to the direction of an action or association between one semantic element and another. For example, in an action description, the relationship between the initiator and receiver of the action is directional. A logical constraint relationship manifests as a conditional or causal connection between different events. For instance, a subsequent event is only allowed to be triggered after a certain prerequisite event has occurred; this constraint between the preceding and following events is a logical constraint relationship. A temporal relationship describes the order in which events occur. For example, one event must begin after another event is completed, or two events can occur simultaneously; these sequential arrangements are temporal relationships. The identification of these three types of relationships can be achieved through dependency parsing of natural language descriptions. Dependency parsing can output grammatical relationships such as subject-verb, verb-object, and modifier-object between words, mapping these grammatical relationships to corresponding directional, logical, or temporal relationships according to predefined rules.

[0023] Based on the identified relationships, the dependencies between different generation requirements are determined. A dependency means that the execution of one generation requirement depends on the output of another; for example, the requirement to generate character dialogue depends on the character's 3D mesh data provided by the requirement to complete the character first. Semantic segments with independent execution objectives are extracted from the natural language description. Each semantic segment corresponds to a task node, which is the basic unit of execution scheduling. Each task node contains executable processing logic, a set of input data identifiers, and a set of output data identifiers. The content described by the semantic segment is the processing logic that the task node needs to execute, and this processing logic can be executed as a relatively complete unit. The start and end boundaries of the semantic segments are determined based on temporal connections. When the action or event corresponding to a semantic segment can be started independently without depending on the intermediate results of other segments, its corresponding processing logic is encapsulated as an independent task node.

[0024] The input data identifier set for each task node originates from the output data identifiers of other task nodes that the task node depends on. Specifically, based on dependencies, if the execution of the current task node requires data generated by an upstream task node, then the output data identifier of that upstream task node is added to the input data identifier set of the current task node. The input data identifier set may also include data identifiers marked as external stable inputs. The output data identifier set for each task node originates from the output target of the semantic segment itself, i.e., the name or number of the data object expected to be generated after the task node executes successfully. These identifier sets are automatically generated during task node construction based on the target information and dependencies in the semantic elements. Even if a task node fails during execution, its input data identifier set and output data identifier set still exist and remain unchanged, because they are inherent defined attributes of the task node, not the execution result. Execution failure only affects the validity and version number of the actual output data, not the identifier set itself.

[0025] After dividing all task nodes, a task sequence for generating simulated live-action dramas is generated according to the dependencies and execution order between the task nodes. The task sequence is an ordered list, where each element is a task node. The order of the nodes follows the constraint of dependencies: if a task node A depends on the output data of task node B, then task node B must be placed before task node A. Therefore, semantic fragments are the analysis units at the natural language level, and task nodes are the scheduling units at the execution level, connected through corresponding mapping relationships.

[0026] Based on the above task sequence, a task dependency mapping table is constructed: a unique task node identifier is assigned to each task node in the task sequence. The task node identifier uses a numerical number format, such as T001, T002, etc., assigned sequentially according to the task node's order in the sequence, or a universally unique identifier format. Simultaneously, the determined input data identifier set and output data identifier set for each task node are read. The input data identifier set refers to the names or numbers of all data objects that the task node needs to read during execution; the output data identifier set refers to the names or numbers of the data objects that will be generated after the task node's successful execution. These identifier sets are automatically generated based on the target information and dependencies in the semantic elements during task node partitioning, and can be directly read here.

[0027] A data production record is established based on the output data identifier set of each task node. This record is used to track the data source. For each output data identifier, the record includes at least two items: the task node identifier that produced the output data identifier, and the version number of the output data. The version number distinguishes different content generated by the same data identifier in different execution rounds. Initially, the version number of each output data identifier is set to 1. Each time the task node is re-executed and generates new output data, the version number is automatically incremented by 1. The value of the version number is managed by a maintained global counter or an independent counter for each task node.

[0028] Each input data identifier in the set of input data identifiers corresponding to the current task node is matched with all existing output data identifiers in the data production record to determine whether the strings of the two data identifiers are the same.

[0029] If a match is successful—that is, if an input data identifier of the current task node corresponds to an output data identifier in the data production record—a directed dependency relationship is established between the task node that produced the output data identifier and the current task node, indicating that data flows from the upstream task node to the current task node. Simultaneously, the version number corresponding to the output data identifier in the data production record is recorded as the input data version number for the current task node for that input data identifier. This input data version number determines which version of data the current task node should read during execution.

[0030] If a match fails—that is, if a given input data identifier for the current task node cannot be matched with any output data identifier in the data production record—then that input data identifier is marked as an external stable input data identifier. This indicates that its data content was not produced by any local task node but originated from an external source. For example, general-purpose skeletal rigging data, basic material libraries, and standard speech libraries are typically marked as external stable inputs.

[0031] During the matching process, if it is detected that the input data identifiers of at least two different task nodes correspond to the same output data identifier in the data production record, a shared data dependency relationship corresponding to the output data identifier is established, indicating that multiple downstream task nodes jointly depend on the same data generated by the same upstream task node, and the task dependency mapping table records which task nodes share this output data identifier.

[0032] Furthermore, when an input data identifier is found to be not a direct match to a single output data identifier in the data production record, but rather a combination of multiple output data identifiers, this input data identifier is recorded as a derived data identifier. A derived data identifier does not directly correspond to the output data identifier of any single task node; instead, it is constructed from multiple existing output data identifiers according to predefined combination rules. A pre-defined derivation rule library records the composition method of each derived data identifier. Each derivation rule includes the following: the name of the derived data identifier, a list of all basic output data identifiers required to compose the derived data identifier, and a combination method identifier for combining these basic data into the derived data. The combination method can be data concatenation, feature fusion, coordinate transformation, format encapsulation, etc.

[0033] When the current input data identifier is determined to be a derived data identifier, a derived rule matching the input data identifier name is searched in the derived rule base. If a matching derived rule is found, all basic output data identifiers listed in the rule are read, and these basic output data identifiers are searched one by one in the data production record to obtain the production task node identifier and the current output data version number corresponding to each basic output data identifier. The current input data identifier is recorded as the derived data identifier, and the following information is recorded: all source task node identifiers that form this derived data identifier, and the output data version number corresponding to each source task node. The combination method identifier in the derived rule is also recorded so that when the task node is actually executed, the required derived input data can be generated from the basic data according to the correct combination method.

[0034] If no derived rule matching the input data identifier can be found in the derived rule base, and the input data identifier cannot be directly matched with any output data identifier in the data production record, then the input data identifier is marked as an external stable input data identifier, and its processing method is the same as the aforementioned matching failure case.

[0035] All collected information is aggregated to generate a task dependency mapping table. This task dependency mapping table represents at least the following: data dependencies between task nodes, i.e., which task nodes' outputs are used as inputs by which task nodes; the data version number corresponding to each input data; shared data dependencies, i.e., the situation where the same output data is used by multiple downstream task nodes; and the source combination of derived data identifiers.

[0036] The execution status of each task node is monitored based on the constructed task dependency mapping table. The specific process is as follows: Based on the data dependency relationships between each task node recorded in the task dependency mapping table, the task node that currently meets the execution conditions is identified.

[0037] The execution condition is that each input data identifier corresponding to a task node can be found in the data production record with a corresponding output data identifier, and the version number of the corresponding input data is consistent with the current version number of the output data identifier in the data production record. Input data marked as externally stable input data identifiers is always in a ready state by default. Task nodes that meet the above execution conditions are scheduled for execution and submitted to the downstream execution engine or processing unit. After the execution engine completes the data generation or processing operation defined for the task node, it returns an execution return result. The execution return result includes at least information on whether the task node completed successfully, and, if successful, the storage location or access path of the generated output data.

[0038] During the scheduling and execution of the current task node, the set of input data version numbers corresponding to that task node is read. Simultaneously, the execution sequence number of the current task node in the task sequence is obtained. Based on the execution sequence number of the current task node and the initial version base, the expected value of the corresponding output data version number is generated according to a preset calculation formula. The calculation formula is the sum of the execution sequence number and the initial version base; the specific formula is determined by the pre-defined personnel during deployment. The expected value of the output data version number represents the theoretical version number that should be assigned to the output data of the task node after successful execution in the current execution round.

[0039] After completing the above reading and calculation, the execution return result, the set of input data version numbers, and the expected value of the output data version number are used together as the basis for determining the execution status to perform status checks on the current task node. Status checks include two aspects: version anomaly detection and execution failure detection. Version anomaly detection refers to determining whether the actual output data version number generated by the current task node is consistent with the expected value of the output data version number. If the actual version number does not match the expected value, it is considered to meet the version anomaly failure condition. Execution failure detection refers to determining whether the task node failed to complete its defined data generation or processing operation based on the success or failure flag in the execution return result. If the execution return result explicitly indicates execution failure, it is considered to meet the execution failure judgment condition.

[0040] When a current task node is detected to meet any one or both of the aforementioned preset version failure conditions or execution failure judgment conditions, it is identified as an execution failure node. After identifying an execution failure node, the scheduling of all subsequent task nodes on the execution path of that execution failure node is terminated. This prevents subsequent task nodes from continuing execution based on unreliable or erroneous data, which could waste computing resources or produce incorrect results. It also triggers the impact propagation computation process targeting the execution failure node. An execution path refers to a link consisting of a series of task nodes extending downstream along the directed dependencies recorded in the task dependency mapping table, starting from a certain task node. Figure 3 The diagram shown is a flowchart corresponding to the influence propagation calculation provided in an embodiment of the present invention. The specific process is as follows: The system reads the set of output data identifiers corresponding to the failed node, as well as the output data version number of each output data identifier in the current execution round. For a failed node, although its output data failed to be generated successfully or the version is abnormal, the expected output data identifier and corresponding version number are still recorded for propagation analysis.

[0041] Traverse the task dependency mapping table to find all task nodes that use the output data identifier as their input data identifier, and identify all task nodes that reference any output data identifier of the failed execution node as their input data identifier. These task nodes constitute a candidate set that may be affected by this failure propagation.

[0042] For each candidate task node found, a version association matching operation is performed, comparing the input data version number recorded by the candidate task node with the output data version number produced by the failed execution node corresponding to that input data identifier.

[0043] When the version number of the input data corresponding to a candidate task node matches the version number of the output data corresponding to a failed execution node, it indicates that the data planned to be used by the candidate task node is precisely the specific version of data that the failed execution node failed to generate. Therefore, the candidate task node has indeed been affected by the current failure. This candidate task node is identified as a propagation task node affected by the current failed node and added to an initial propagation queue. The initial propagation queue is a first-in, first-out (FIFO) data structure used to temporarily store affected task nodes awaiting further processing.

[0044] While adding the task node to be propagated to the initial propagation queue, it is also necessary to record the propagation metadata related to that node. Specifically, this includes: recording the propagation source node of the task node to be propagated as the currently processed execution failure node; and recording the data dependency type between the task node to be propagated and the propagation source node. Data dependency types include one or more of direct dependency, shared data dependency, and derived data dependency. Direct dependency means that the input data identifier of one task node directly matches the output data identifier of another task node. Shared data dependency means that the input data identifiers of multiple task nodes point to the same output data identifier, and that output data identifier is produced by the same task node. Derived data dependency means that the input data identifier of a task node is a derived data identifier, and the underlying output data identifier it depends on includes the output data identifier of the currently failed execution node.

[0045] When the version number of the input data corresponding to a candidate task node is inconsistent with the version number of the output data corresponding to a failed execution node, it is determined that the candidate task node has not been affected by the current failure propagation. Possible reasons for version inconsistency include: the version number of the input data recorded by the candidate task node has been updated to an updated version produced by another task node, or the candidate task node depends on another historical version identified by the output data. For such candidate task nodes, they are not added to the initial propagation queue.

[0046] After processing all found candidate task nodes, the currently processed failed execution node is marked as a processed node, indicating that the initial analysis of the direct propagation impact of that node has been completed. Finally, the constructed initial propagation queue is output, which contains all task nodes to be propagated that are directly affected by the currently failed execution node and whose versions match.

[0047] Recursive propagation analysis is performed on the initial propagation queue to determine the complete set of task nodes indirectly affected by all execution failure nodes. For example... Figure 4 The diagram shown is a flowchart corresponding to the recursive propagation analysis provided in an embodiment of the present invention. The specific process is as follows: Each task node in the initial propagation queue is taken out in turn as the current task node, and the current task node is added to an affected node set. This set is used to record the data structure of all task nodes that are determined to be affected by the failure propagation. The initial state is empty, and it is continuously expanded as the processing progresses.

[0048] For each task node currently being processed, based on the constructed task dependency mapping table, traverse the input data identifier list of all task nodes in the task dependency mapping table, filter out the task nodes that reference any output data identifier of the current task node, and use the output data identifier of the current task node as the downstream task node of the input data identifier. The set of input data identifiers of downstream task nodes contains the task nodes of a certain output data identifier of the current task node.

[0049] For each downstream task node found, a version consistency check is performed, comparing the input data version number recorded by the downstream task node corresponding to the input data identifier with the output data version number corresponding to the current task node when it produced the output data identifier.

[0050] When the input data version number of a downstream task node is inconsistent with the output data version number of the current task node, it indicates that the data version expected to be used by the downstream task node is not the version generated by the current task node. Therefore, the downstream task node should not be affected by the current failure propagation, the propagation branch should be terminated, and the analysis of the downstream task node and its downstream nodes should not continue.

[0051] When the input data version number of a downstream task node matches the output data version number of the current task node, the execution status of that downstream task node is further determined. The execution status is obtained from the task execution log or status table, including not executed, executing, executed successfully, and executed failed.

[0052] If the downstream task node has executed successfully and its output data has not been used as input data by any unexecuted task node, then even if the upstream node fails, the output data already generated by the downstream task node is still valid and will not be depended upon by future unexecuted task nodes. Therefore, this propagation branch is terminated, and the downstream task node is no longer included in the affected scope. The task dependency mapping table is traversed through the set of input data identifiers for all unexecuted task nodes, checking if any of the downstream task node's output data identifiers are included. If not, the output data is considered to have been used as input data by unexecuted task nodes.

[0053] If the above termination conditions are not met, i.e., the downstream task node has not yet been executed successfully, or its output data is still dependent on the unexecuted task node, then the downstream task node is added to the set of affected nodes and added to a pending queue to store task nodes that need to be further propagated downstream for analysis.

[0054] In the propagation analysis process, two special dependency relationships also need to be handled: shared data dependency and derived data dependency. For downstream task nodes associated due to shared data dependency, that is, multiple downstream task nodes jointly depend on the same output data of the same upstream task node, they are processed according to the same version matching rules as mentioned above. Each downstream task node with shared dependency is checked one by one. If its input data version number is consistent with the upstream output data version number, and the downstream task node has not yet been added to the affected node set, then it is added to the affected node set and the pending queue.

[0055] For downstream task nodes associated with derived data dependencies, i.e., the input data identifier of the downstream task node is a derived data identifier, and the basis of the derived data identifier includes the output data identifier of the current task node, the propagation determination is also performed. It is checked whether the version numbers of all the basic output data identifiers that the derived data identifier depends on match the version numbers in the current propagation chain. If the propagation conditions are met and the downstream task node has not yet been added to the affected node set, it is added to the affected node set and the pending queue. Among the basic output data identifiers that the derived data identifier depends on, at least one comes from the current failed propagation chain, and the version numbers of all basic data are consistent with the requirements of the downstream task node records.

[0056] Here, meeting the propagation conditions means simultaneously meeting the following three requirements: 1. The input data identifier of the downstream task node is a derived data identifier, and the output data identifier of the current task node is included in the composition of the derived data identifier.

[0057] 2. The version numbers of all basic output data identifiers upon which this derived data identifier depends are consistent with the version numbers output by the corresponding production task nodes in the current propagation chain.

[0058] 3. The downstream task node has not yet been executed successfully, or although it has been executed successfully, its output data is still being used as input data by at least one unexecuted task node.

[0059] Repeat the above processing flow, sequentially retrieving task nodes from the pending queue as new current task nodes, finding their downstream nodes and performing version consistency checks, execution status checks, and special dependency handling, until the pending queue becomes empty. When the pending queue is empty, it indicates that all task nodes directly or indirectly affected by this failure propagation have been identified. Output the final set of affected nodes, along with the data dependencies corresponding to each affected node in this set.

[0060] After completing the recursive propagation analysis, a minimal replanning subgraph is constructed based on the obtained set of affected nodes. This subgraph consists only of task nodes affected by failure propagation and requiring replanning, along with their data dependencies. The construction process is as follows: Read the task node identifier, input data identifier set, output data identifier set, and corresponding data version number of each task node in the affected node set, and extract the directed dependency relationship between each task node in the affected node set based on the task dependency mapping table.

[0061] In this context, a directed dependency means that if the output data identifier of task node A is used as the input data identifier of task node B, then a directed edge is established between A and B, pointing from A to B. An initial subgraph is constructed based on these directed edges. This initial subgraph currently only contains nodes from the affected node set and the direct dependencies between them.

[0062] For each task node in the initial subgraph, the source of the input data identifier is determined. For a given input data identifier, it is determined whether the task node that produced the data identifier belongs to the current set of affected nodes. The corresponding production task node identifier is searched in the task dependency mapping table. If the production task node identifier is not in the current set of affected nodes, the input data identifier originates from an unaffected node. For input data identifiers originating from unaffected nodes, the corresponding input data version number is further checked to see if it matches the current version number of the data identifier recorded in the task dependency mapping table.

[0063] If the version numbers match, the input data is marked as an external stable input, indicating that the data content is reliable and does not need to be regenerated in this replanning. If the version numbers do not match, it means that although the unaffected node itself is not marked as a failure propagation impact, the version of the data it generates does not match the version that the task node in the current subgraph depends on. In this case, the production task node is added to the set of affected nodes, and the initial subgraph is updated, that is, the dependency relationship between the newly added node and the original nodes is re-extracted.

[0064] Repeat the above source determination and subgraph update process until the set of affected nodes no longer expands. Each expansion may introduce new nodes, which may also have input data identifiers from other unaffected nodes, requiring further determination. Therefore, this is an iterative convergence process.

[0065] Once the set of affected nodes stabilizes, the initial subgraph is pruned, deleting all task nodes not belonging to the final set of affected nodes, retaining only the task nodes in the final set and their directed dependencies. During pruning, if an input data identifier for a task node cannot be found in the task dependency mapping table and is not marked as an external stable input, it is marked as a missing input. A missing input means the source of the data cannot be determined, thus compromising the integrity of the replanning subgraph. At this point, the construction of the minimum replanning subgraph is terminated, and an error is reported to the upper layer. If all input data identifiers have a valid source or have been marked as external stable inputs, the completed minimum replanning subgraph is successfully output.

[0066] After obtaining the minimum replanning subgraph, a consistency check is performed on it. The specific process of the consistency check is as follows: Obtain the set of input data version numbers and the set of output data version numbers corresponding to each task node in the minimum replanning subgraph. For each task node, perform a consistency check on its input data identifier and corresponding input data version number. The purpose of the consistency check is to discover version conflicts or version mismatches in the input data of that node.

[0067] When the same input data identifier corresponds to multiple different input data version numbers in the input data version number set of a task node, the task node is considered to have an input version conflict. Input version conflicts typically occur because the input data identifier is produced by multiple upstream task nodes, and the current node depends on these different versions of data simultaneously. In this case, data consistency cannot be guaranteed. Task nodes with input version conflicts are marked as task nodes that must be re-executed.

[0068] When each input data identifier of a task node corresponds to a unique input data version number, and all of these input data identifiers are marked as originating from stable external inputs, the task node is marked as a skippable task node. This means that all the input data that the node depends on comes from stable external sources that are not affected by this failure, and the versions are unique and conflict-free. Therefore, the original execution results of the node can be directly reused without re-execution.

[0069] When the version number of a certain input data does not match the version association record in the minimum replanning subgraph, the corresponding task node will also be marked as a task node that must be re-executed. The version association record refers to the correspondence between each input data identifier recorded during the construction of the minimum replanning subgraph and the output version number of its production task node. If the version number recorded by the current node is inconsistent with the output version number recorded by the production task node in the subgraph, it means that the node depends on the old version data and must be re-executed to obtain a result compatible with the new version data.

[0070] After completing the consistency check, the execution flag for each task node is obtained, including whether it can be skipped or must be re-executed. Local replanning and replacement operations are then performed, as follows: For nodes marked as skippable task nodes, their original execution results and output data version numbers are retained, and the nodes are not rescheduled for execution.

[0071] For nodes marked as requiring re-execution, reschedule execution based on the task dependency mapping table. Before execution, update the input data version number of the task node to the corresponding determined input data version number in the minimum replanning subgraph to ensure that the node uses the same version number as the current replanning subgraph when re-executed. Figure 1 The version of the input data.

[0072] When a task node that must be re-executed successfully re-executes, the output data version number and data production record corresponding to that node are updated. The update method is as follows: read the current output data version number of the node, generate a new version number according to the method described in step S2, typically incrementing the original version number; simultaneously, update the production task node identifier and version number corresponding to the output data identifier in the data production record. Following the directed dependencies in the task dependency mapping table, the updated version information is passed to downstream task nodes. This is done by updating the corresponding input data version number in the downstream task nodes to the new version number and marking these downstream nodes as needing to have their execution status rechecked.

[0073] When a task node fails to be re-executed, the impact propagation calculation for that task node is triggered. That is, the processing flow described in steps S2 and S3 is repeated, and this failure is used as a new source of failure for propagation analysis.

[0074] After completing the re-execution and version update of all necessary task nodes, the original output data is replaced based on the output data generated by the re-execution. Old output data in the cache or storage is marked as invalid, and the newly generated data and its version number are written to the corresponding storage location. Simultaneously, the input data version number of the corresponding task node in the task dependency mapping table is updated to ensure that the correct data version is read during subsequent task node scheduling.

[0075] For nodes marked as requiring re-execution due to shared data dependencies or derived data dependencies, the output data version information of their corresponding source task node needs to be read before re-execution, and the corresponding re-execution input data needs to be generated accordingly.

[0076] Specifically, for cases involving shared data dependencies, the latest version number of the shared data is retrieved from the data production record and used as the input data version number for that node. For cases involving derived data dependencies, the latest version numbers of all basic output data identifiers constituting the derived data identifier are first retrieved. Then, based on the combination method identifier recorded in the derived rule base, the corresponding combination function is called to synthesize multiple basic data into derived input data, which is then provided to the task node for execution.

[0077] After completing the scheduling and version updates of all necessary re-execution task nodes, the scheduling and execution of subsequent task nodes resume. These subsequent task nodes refer to those that were originally aborted due to upstream execution failures, as well as downstream task nodes that need to be re-executed in this round of replanning due to version updates. According to the dependencies in the task dependency mapping table, the execution conditions of these subsequent task nodes are re-checked. Once all input data is ready and version consistent, it is submitted to the execution engine. At this point, the local replanning and replacement operations are complete, and the subsequent live-action drama generation task continues.

[0078] like Figure 5 The diagram shown is a structural schematic of the simulated live-action drama automatic choreography system based on natural language generation provided in an embodiment of the present invention. The simulated live-action drama automatic choreography system based on natural language generation provided in an embodiment of the present invention includes the following modules: The semantic parsing and labeling module is used to perform semantic parsing on the natural language description received as input to obtain the task sequence for generating the simulated live-action drama. Based on the task sequence, a task dependency mapping table is constructed, and input data identifiers and output data identifiers are labeled for the task nodes corresponding to each task sequence in the task dependency mapping table.

[0079] The impact propagation analysis module is used to monitor the execution status of each task node based on the task dependency mapping table. When any task node fails to execute, the corresponding impact propagation calculation process is triggered to determine the corresponding set of output data identifiers.

[0080] The local replanning and replacement module is used to perform recursive propagation analysis on the output data identifier set to obtain the minimum replanning subgraph, perform consistency verification, generate the corresponding node execution tag set, and perform local replanning and replacement on the minimum replanning subgraph to update the scheduling results and execution status of the corresponding task nodes.

[0081] When a user inputs natural language text describing an ancient-style adventure storyline, including multiple generation requirements such as character appearances, scene transitions, dialogue interactions, and action effects, the system first performs semantic parsing: segmenting the text into word units, identifying semantic elements such as character identity, scene environment, event objectives, and temporal sequence, and dividing semantic fragments with independent execution objectives into multiple task nodes based on pointing relationships, logical constraints, and temporal connections. These nodes include character model generation nodes, scene rendering nodes, dialogue synthesis nodes, and action effect nodes. Subsequently, a task sequence is generated according to dependencies, and each task node is labeled with input and output data identifiers. For example, the character model node outputs character mesh data, while the dialogue synthesis node requires input character mesh data and voice library data. A task dependency mapping table is further constructed to record the data dependencies between nodes, data version numbers, and stable external input sources.

[0082] During task scheduling and execution, the character model node successfully executed and output character data with an initial version number. The scene rendering node, which depends on this character data, executed smoothly. When the dialogue synthesis node was executed, it was determined to be a failed node due to a temporary read exception in the voice library data it depended on. The scheduling of subsequent task nodes on the execution path of this node was aborted, and the impact propagation calculation was triggered. By looking up the task dependency mapping table, it was found that the motion effects node also indirectly depends on the output of the dialogue synthesis node. Therefore, the dialogue synthesis node and the motion effects node were included in the initial propagation queue.

[0083] A recursive propagation analysis is then performed, extending downstream along the dependency chain and utilizing version consistency and execution status checks to ultimately obtain a set of affected nodes containing only dialogue synthesis nodes and motion effect nodes. Based on this, a minimal reprogramming subgraph is constructed. After consistency checks, both nodes are marked as tasks that must be re-executed. Local reprogramming is then performed on these two nodes, rescheduling the dialogue synthesis node, successfully executing it using backup voice library data from the stable external input, and updating the output data version number; the motion effect node reads the updated dialogue data and re-executes. After completion, the scheduling of subsequent task nodes is restored, and the entire simulated live-action drama automatic arrangement process continues, ultimately providing the user with a coherent episode output without requiring a complete regeneration.

[0084] like Figure 6This paper demonstrates the accuracy trends of the proposed method and six baseline models (GPT-4.1, Gemini-2.5-pro, GPT-4.1-mini, DeepSeek-R1, Qwen-max, and GPT-4o) in multiple rounds of iterative optimization within the aforementioned scenario of automatically arranging ancient-style adventure storylines. In this scenario, accuracy is defined as the comprehensive score of the generated simulated live-action drama across four dimensions: plot coherence, character consistency, scene logic rationality, and task execution correctness, with a maximum score of 100 points. After each iteration, professional evaluators independently score the generated drama content according to a unified scoring standard, and the average score is taken as the accuracy for that round.

[0085] The results from iterations 0-6 show that the accuracy of all baseline models improved after six iterations. However, the improvement process of the method in this paper was smoother and did not fluctuate significantly. This verifies that the iterative optimization mechanism based on task dependency mapping and local replanning in this paper can effectively and stably improve the generation quality of the automatic arrangement of simulated live-action dramas, avoid the need for overall regeneration due to local task failures, and thus ensure the continuity and efficiency of the drama output.

[0086] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the flow or function according to the embodiments of the present invention is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. A computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0087] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0088] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0089] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0090] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0091] In the embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only 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 device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0092] 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 network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0093] In addition, 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.

[0094] If a function 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, or the part that contributes to the prior art, or a 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, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0095] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for automatically choreographing simulated live-action dramas based on natural language generation, characterized in that: Includes the following steps: S1: When the input natural language description is received, the natural language description is semantically parsed to obtain the task sequence for generating the simulated live-action drama. A task dependency mapping table is constructed based on the task sequence, and the input data identifier and output data identifier are marked for the task node corresponding to each task sequence in the task dependency mapping table. S2: Based on the task dependency mapping table, monitor the execution status of each task node. When any task node fails to execute, trigger the corresponding impact propagation calculation process to determine the corresponding output data identifier set. S3: Perform recursive propagation analysis on the output data identifier set to obtain the minimum replanning subgraph, perform consistency verification, generate the corresponding node execution tag set, and perform local replanning and replacement on the minimum replanning subgraph to update the scheduling results and execution status of the corresponding task nodes.

2. The method for automatically arranging simulated live-action dramas based on natural language generation as described in claim 1, characterized in that, The specific process of semantic parsing is as follows: The natural language description is segmented and semantically identified to extract semantic elements that represent the plot theme, character identity, scene environment, event goals and time sequence. Based on the pointing relationships, logical constraints, and temporal connections between semantic elements, the dependencies between different generation requirements are identified, and semantic fragments with independent execution goals are divided into corresponding task nodes. Based on the dependencies and execution order between each task node, a task sequence for generating simulated live-action dramas is generated.

3. The method for automatically choreographing simulated live-action dramas based on natural language generation as described in claim 2, characterized in that, The process of constructing the task dependency mapping table is as follows: Assign a corresponding task node identifier to each task node in the task sequence, and read the input data identifier set and output data identifier set corresponding to each task node; A data production record is established based on the output data identifier set of each task node. The data production record includes at least the production task node identifier of the output data identifier and the output data version number. Match the input data identifier corresponding to the current task node with the output data identifier in the data production record: If the match is successful, a directed dependency relationship is established between the task node that produces the corresponding output data identifier and the current task node, and the output data version number is recorded as the input data version number corresponding to the current task node. If a match fails, the corresponding input data identifier will be marked as an external stable input data identifier. When the input data identifiers of at least two task nodes correspond to the same output data identifier, a shared data dependency relationship corresponding to the output data identifier is established; When an input data identifier is formed by combining multiple output data identifiers, the input data identifier is recorded as a derived data identifier, and the source task node identifier and the corresponding output data version number that form the derived data identifier are recorded. Generate a task dependency mapping table, which is used to represent the data dependencies, data version numbers, shared data dependencies, and source combinations of derived data between task nodes.

4. The method for automatically choreographing simulated live-action dramas based on natural language generation as described in claim 3, characterized in that, The monitoring of the execution status of each task node includes: Based on the dependency relationships between task nodes in the task dependency mapping table, task nodes that meet the execution conditions are scheduled for execution, and the corresponding execution return results are recorded. During the execution of the current task node, the set of input data version numbers corresponding to the current task node is read, and the expected value of the corresponding output data version number is generated according to the execution sequence number of the current task node and the preset initial version base. The execution return result, the set of input data version numbers, and the expected value of the output data version number are used as the basis for determining the execution status, and the status of the current task node is detected. When the current task node is detected to meet the preset version abnormal failure conditions and / or execution failure judgment conditions, the current task node is determined as an execution failure node, and the scheduling of subsequent task nodes on the execution path where the execution failure node is located is stopped, triggering the impact propagation calculation of the execution failure node.

5. The method for automatically choreographing simulated live-action dramas based on natural language generation as described in claim 4, characterized in that, The specific process for calculating the impact propagation of the failed execution node is as follows: Read the set of output data identifiers corresponding to the execution failure node and the output data version number corresponding to each output data identifier; Based on the task dependency mapping table, find all task nodes that use the output data identifier as the input data identifier; The found task nodes are matched for version association. When the version number of the input data corresponding to the task node is consistent with the version number of the output data corresponding to the failed execution node, the task node is identified as a task node to be propagated that is affected by the current failed node and added to the initial propagation queue. While adding the task node to be propagated to the initial propagation queue, the propagation source node corresponding to the task node to be propagated is recorded as the execution failure node, and the corresponding data dependency type is recorded. The data dependency type includes at least one of direct dependency, shared data dependency and derived data dependency. When the version number of the input data corresponding to the task node is inconsistent with the version number of the output data corresponding to the execution failure node, it is determined that the task node is not affected by the current failure propagation and is not added to the initial propagation queue. The nodes that failed to execute are marked as processed nodes, and the corresponding initial propagation queue is output.

6. The method for automatically choreographing simulated live-action dramas based on natural language generation as described in claim 5, characterized in that, The specific process of the recursive propagation analysis is as follows: The task node in the initial propagation queue is taken as the current task node, and the current task node is added to the set of affected nodes; Based on the task dependency mapping table, find all downstream task nodes that use the output data identifier of the current task node as the input data identifier; Version consistency is determined for each downstream task node. When the version number of the input data of the downstream task node is inconsistent with the version number of the output data of the current task node, the corresponding propagation branch is terminated. When the input data version number of the downstream task node is consistent with the output data version number of the current task node, the execution status of the downstream task node is further determined. If the downstream task node has been executed successfully and its output data is not used as input data for the unexecuted task node, then the corresponding propagation branch is terminated. Otherwise, add the downstream task node to the affected node set and the pending queue; For downstream task nodes corresponding to shared data dependencies, according to the same version matching rules, task nodes that meet the conditions but have not been added to the affected node set are added to the affected node set and the pending queue. For the downstream task nodes corresponding to the derived data dependency, the task nodes that meet the propagation conditions but have not been added to the affected node set will be added to the affected node set and the pending queue. Repeat the above process until the queue is empty, and output the final set of affected nodes and the data dependencies of each affected node.

7. The method for automatically choreographing simulated live-action dramas based on natural language generation as described in claim 6, characterized in that, The construction process of the minimum replanning subgraph is as follows: Read the task node identifier, input data identifier set, output data identifier set, and corresponding data version number of each task node in the affected node set; Based on the task dependency mapping table, the directed dependencies between each task node in the affected node set are extracted to construct an initial subgraph; The source of the input data identifier of each task node in the initial subgraph is determined. When any input data identifier comes from an unaffected node and its corresponding input data version number is consistent with the record in the task dependency mapping table, the input data identifier is marked as an external stable input. When any input data identifier originates from an unaffected node and its corresponding input data version number is inconsistent with the record in the task dependency mapping table, the task node that produced the input data identifier is added to the set of affected nodes, and the initial subgraph is updated. Repeat the above source determination and subgraph update process until the set of affected nodes no longer expands; Delete task nodes in the initial subgraph that do not belong to the affected node set, and retain only the task nodes in the affected node set and their directed dependencies; When the input data identifier of a task node cannot be found in the task dependency mapping table and is not marked as an external stable input, the corresponding input data identifier is marked as a missing input, and the construction of the minimum replanning subgraph is terminated. Otherwise, output the minimum replanning subgraph.

8. The method for automatically arranging simulated live-action dramas based on natural language generation as described in claim 7, characterized in that, The consistency verification process is as follows: Obtain the set of input data version numbers and the set of output data version numbers corresponding to each task node in the minimum replanning subgraph; Perform consistency verification on the input data identifier and corresponding input data version number of each task node; When the same input data identifier corresponds to multiple input data version numbers, it is determined that there is an input version conflict in the corresponding task node, and the corresponding task node is marked as a task node that must be re-executed. When each input data identifier corresponds to a unique input data version number and all of them originate from stable external input, the corresponding task node is marked as a skippable task node. When any input data version number does not match the version association record in the minimum replanning subgraph, the corresponding task node is marked as a task node that must be re-executed.

9. The method for automatically choreographing simulated live-action dramas based on natural language generation as described in claim 8, characterized in that, The specific process of the local replanning and replacement is as follows: For nodes marked as skippable task nodes, their original execution results and output data version numbers are retained, and they are not rescheduled for execution. For nodes marked as task nodes that must be re-executed, the task is rescheduled and executed based on the task dependency mapping table, and the input data version number is updated to the corresponding input data version number determined in the minimum replanning subgraph before execution. When a task node that must be re-executed successfully is successfully re-executed, its corresponding output data version number and data production record are updated, and the updated version information is passed to the downstream task node along the directed dependency relationship in the task dependency mapping table. When a task node fails to be re-executed, the impact propagation calculation for that task node is triggered. The original output data is replaced based on the output data generated by re-execution, and the input data version number of the corresponding task node in the task dependency mapping table is updated synchronously. For nodes marked as requiring re-execution due to shared data dependencies or derived data dependencies, the output data version information of their corresponding source task node is read before re-execution, and the corresponding re-execution input data is generated. After completing the scheduling and execution of all necessary re-execution task nodes and version updates, resume the scheduling and execution of subsequent task nodes to complete local replanning and replacement.

10. An automatic scheduling system for simulated live-action dramas based on natural language generation, comprising the following modules: The semantic parsing and labeling module is used to perform semantic parsing on the natural language description when it receives the input natural language description, so as to obtain the task sequence for generating the simulated live-action drama, construct a task dependency mapping table based on the task sequence, and label the input data identifier and output data identifier for the task node corresponding to each task sequence in the task dependency mapping table. The impact propagation analysis module is used to monitor the execution status of each task node based on the task dependency mapping table. When any task node fails to execute, the corresponding impact propagation calculation process is triggered to determine the corresponding set of output data identifiers. The local replanning and replacement module is used to perform recursive propagation analysis on the output data identifier set to obtain the minimum replanning subgraph, perform consistency verification, generate the corresponding node execution tag set, and perform local replanning and replacement on the minimum replanning subgraph to update the scheduling results and execution status of the corresponding task nodes.

Images