Large-scale planning problem solving method based on general knowledge of large language model

Abstract

The application relates to the field of artificial intelligence and automatic planning, and in particular to a large-scale planning problem solving method based on general knowledge of a large language model, which comprises the following steps: parsing a PDDL domain file and an instance file to obtain an initial state, a target state and an action model; decomposing the target state into sub-targets in the form of directed binary tuples, constructing a directed acyclic dependency graph and topologically sorting to obtain an ordered sub-target sequence; recursively traversing the sequence to generate sub-problems and calling a planner to solve the sub-problems, and if the solving fails or times out, optimizing through two modes of the LLM; mode A selects actions from an executable action sequence to compress a search space, and mode B predicts an intermediate state to split an intermediate sub-problem; and finally, sequentially concatenating sub-plans to generate an overall plan; the application aims to solve the problems of large search overhead, difficulty in determining the order of sub-targets and unreliable LLM output of a traditional planning method.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and automated planning, and in particular to a solution for large-scale planning problems based on general knowledge of large language models. Background Technology

[0002] In the fields of artificial intelligence and automated planning, the core of solving complex structured planning problems lies in generating legal action sequences based on standardized descriptions. Planning Domain Definition Language (PDDL), as a key carrier connecting problem modeling and planner solving, has become the mainstream technological support in this field. Traditional planning methods explore the state space through techniques such as heuristic search and graph planning. However, with the breakthroughs of Large Language Models (LLM) in commonsense reasoning and semantic understanding, their integration with traditional planning techniques has become an important direction for improving the ability to solve complex planning problems.

[0003] In production and practical use, existing planning methods still face three core problems. First, the search overhead is too high. Traditional classical planning is prone to state space explosion when the size of the object and the number of executable actions increase, making it difficult to obtain a high-quality solution within the time limit. Second, the order of sub-objectives is difficult to determine. Although methods such as hierarchical decomposition can reduce global complexity, they lack a systematic mechanism for determining the order. The order of solving sub-tasks directly affects the overall solvability and efficiency. Third, LLM output is unreliable. Existing planning methods combined with LLM either have problems such as illegal actions and unreachable states, or the lack of strict domain constraints leads to output actions that do not meet the preconditions, affecting the reliability of the planning. These problems make it difficult for existing technologies to balance solution efficiency and result validity when dealing with large-scale, strongly coupled, complex structural planning tasks.

[0004] A search revealed a patent, CN117874258A, titled "Intelligent Planning Method for Task Sequences Based on a Large-Scale Language Visual Model and Knowledge Graph." The core principle of this patent is to construct a hierarchical knowledge graph to store object attributes, action attributes, and relationships between objects. It then uses the VisualBERT large-scale language visual model to process scene images and task text, extracting initial relationship triples between scene objects and predicting target state triples. Based on the knowledge graph and the aforementioned state information, it automatically generates PDDL domain files and question files. Finally, a PDDL planner solves for the action primitive sequence. From a production application perspective, this method's advantages lie in improving the autonomy and scene adaptability of PDDL file generation. The combination of the large model and knowledge graph reduces manual intervention and can adapt to scenarios with varying tasks, such as daily home life. However, its disadvantages are also significant. This method focuses on the automatic generation of PDDL files and does not provide systematic solutions for optimizing the order of sub-objectives and compressing the search space. It cannot alleviate the problems of state space explosion and unreasonable sub-objective order in complex problems. Furthermore, it does not effectively constrain the output of the large language model, leaving a risk of unreliable output. In addition, existing related methods either rely solely on traditional planning techniques, which are insufficient to handle large-scale and complex problems, or simply rely on large language models to generate action sequences end-to-end, which cannot guarantee the validity of the results.

[0005] In summary, existing methods have failed to simultaneously address the three core problems of excessive search overhead, difficulty in determining the order of sub-objectives, and unreliable LLM output. Therefore, this invention adopts a technical approach of "systematic decomposition of objectives - ordered planning of dependencies - constrained LLM assistance". Through directed binary sub-objective decomposition, topological sorting of directed acyclic dependency graphs, and two constrained application modes of LLM, it achieves more efficient and reliable solutions to complex structured planning problems. Summary of the Invention

[0006] This invention provides a solution to large-scale planning problems based on the general knowledge of large language models, in order to address the problems of excessive search overhead, difficulty in determining the order of sub-objectives, and unreliable output of large language models (LLM) in complex structured planning problems by traditional planning methods.

[0007] To solve the above problems, the technical solution adopted by the invention is as follows:

[0008] A method for solving large-scale planning problems based on general knowledge of large language models is characterized by the following steps:

[0009] Step 1. Parsing and Modeling: Receive the PDDL domain file and instance file, and parse them to obtain the initial state. Target state and motion models The target state Composed of several sub-objectives Composition, sub-targets The form is an ordered pair;

[0010] Step 2. Target Decomposition: Decompose the target state Decompose into several sub-objectives in the form of directed binary tuples All sub-targets Insert into the preprocessing sequence;

[0011] Step 3. Dependency Graph Construction and Sorting: Based on Sub-goals in the Preprocessed Sequence Construct Directed Acyclic Dependency Graphs (DADGs), perform topological sorting on the DADGs, and obtain ordered sub-target sequences. ;

[0012] Step 4. Subproblem generation and solution: Recursively traverse the ordered sub-target sequence, and sort the sub-targets in order. Loading subproblem subproblems satisfy ,in This represents the initial state of the subproblem, which is also the current state. The planner is then invoked to solve the subproblem. If the planning is successful, a sub-plan will be obtained. Proceed to step 6; if it fails or times out, proceed to step 5.

[0013] Step 5. Utilize Large Language Models (LLM) to reduce the search domain and simplify the complexity of subproblems, specifically including the following two application patterns:

[0014] Mode A: Invoke LLM to select an action from the sequence of executable actions, compressing the search space. The specific process is as follows:

[0015] A1. Obtain the executable action sequence: Pass the current state to the successor generator. And the action model M, the successor generator outputs an executable action sequence. ;

[0016] A2.LLM selects the next action: Passes the current state to the LLM. Target state Given an executable action sequence A, the LLM selects an action from the executable action sequence A. And return; A3. Update the current state: Input the current state into the state converter. and actions The state converter outputs the updated current state. Return to step 4 to continue solving the subproblem. ;

[0017] Mode B: Invoke LLM to predict intermediate states and break down sub-problems. The specific process is as follows:

[0018] B1. Obtaining intermediate states: Passing the current state to the LLM and target state LLM returns to an intermediate state intermediate state It consists of 1-2 key predicates;

[0019] B2. Generating new subproblems: Constructing intermediate subproblems and , This is the first sub-problem in the middle of the split. This is the second sub-problem that has been split in the middle;

[0020] B3. Obtaining the solution path for the new problem: Calling the planner to calculate intermediate subproblems. Action path If the planning is successful, the action path will be executed. If the planning fails, return to step B1 to retrieve the intermediate state again. ;

[0021] B4. Update the current state: Input the current state into the state converter. and action path The state converter outputs the updated current state. Return to step 4 to continue solving the subproblem. ;

[0022] Step 6. Sub-plan merging: Merge all sub-plans Generate the overall plan by concatenating the ordered sub-objective sequences in sequence. .

[0023] The principle and advantages of this scheme are as follows:

[0024] First, the system receives the PDDL domain file and instance file and parses them to obtain the initial state, target state, and action model. The target state is then decomposed into several sub-objectives in the form of directed binary tuples, and a preprocessing sequence is constructed. Next, a directed acyclic dependency graph (DADGs) is built based on the dependencies between sub-objectives. A topological sort is used to determine the ordered sub-objective sequence, fundamentally solving the problem of disordered sub-objective order. Then, the ordered sub-objective sequence is recursively traversed, and each sub-objective and the current state are packaged into a subproblem and solved using the planner. If the solution fails or times out, the solution process is optimized using two constrained LLM application modes: In Mode A, the process proceeds sequentially from the initial state to the next state. The algorithm outputs the executable action sequence in the current state, then passes the current state, target state, and action sequence to the LLM, constraining the LLM to select legal actions. After the state converter updates the current state, the algorithm is solved again, achieving directional compression of the search space. In mode B, the current state and target state are passed to the LLM, constraining it to return an intermediate state composed of 1-2 key predicates. Based on this, the atomic problem is split into two smaller sub-problems. The planner solves the new sub-problems to obtain action paths and updates the current state, achieving hierarchical simplification of complex problems. Finally, all sub-plans are concatenated according to the ordered sub-target sequence to generate the overall planning scheme.

[0025] Compared to existing technologies, which either lack a systematic decomposition and sorting mechanism or rely on manual or experience-based methods to determine the order of subtasks, this solution achieves automatic and reasonable determination of the order of sub-objectives through directed binary tuple decomposition and directed acyclic dependency graph topological sorting. For example, in the Blocks domain, the target state... It can be automatically split into ordered sub-target sequences { }>{ }>{ }, where the above expression is the standard predicate expression of the PDDL planning domain definition language, which is common in the field of intelligent planning. The binary predicate defined for PDDL represents the stacking state of block x placed on top of block y. The overall target state corresponding to this set of expressions is: block C stacked on block B, block D stacked on block C, and block B stacked on block A. This avoids the efficiency loss caused by invalid solution order and significantly improves planning efficiency. Existing end-to-end LLM planning methods directly generate complete action sequences from the model, lacking explicit constraints on domain rules, such as action preconditions and object interaction constraints. This easily leads to the output of actions that do not meet the execution prerequisites, such as generating a "pick-up action" without meeting the "robotic arm is idle" condition or invalid actions outside the domain scope, resulting in the inability to guarantee action legality. Existing heuristic guidance methods only guide LLM to provide search direction through general prompts, without incorporating domain-specific constraints, such as... While action effects and state transition rules are integrated into the guiding logic, they still suffer from issues such as conflicts between output actions and domain rules, and lack of executable feasibility. This solution addresses these problems by employing two constrained modes to ensure the reliability of LLM output: Mode A constrains the LLM to select actions from a sequence of executable actions, preventing actions that do not meet preconditions from being output; Mode B limits intermediate states to 1-2 key predicates, reducing the difficulty of LLM reasoning and ensuring the validity of intermediate states. For example, when the current state is {(ONTABLEC)(ONTABLEA)(ONTABLEB)(ONTABLED)} and the target state is {(ONCB)(ONDC)(ONBA)}, the LLM returns the intermediate state (ONBA), splitting the original problem into two easily solvable sub-problems, significantly reducing the search space. Existing technologies struggle to balance search efficiency and result validity. This solution, through a full-process design of "split-sorting-constrained assistance-merging," not only utilizes traditional planners to ensure the validity of actions and the reachability of states, but also overcomes the bottleneck of state space explosion through LLM assistance. Furthermore, it is decoupled from existing planners, possessing strong versatility and scalability. Furthermore, the combination of orderly planning among sub-goals and constrained LLM assistance ensures the legitimacy of the overall plan without complex conflict resolution after the sub-plans are merged. For example, after multiple sub-plans are linked together, the execution results of the preceding sub-plans will not destroy the preconditions of the subsequent sub-plans, which greatly reduces the verification cost and execution risk of the overall plan.

[0026] Furthermore, in step 1, when parsing the PDDL domain file and instance file, a dictionary structure is created to store the parsing results. The dictionary structure is as follows: {'metric':XXX,'pred':['on',['object','object']]…,'instance':{'init':{'functions':XXX,'pred':XXX},'goal':XXX,'object':XXX,},'domain':{'pick-up':{'params':XXX,'pos_prec':XXX,'adds':XXX,'del s':XXX}…}}, where metric is the metric, pred is the predicate definition, instance-init is the initial state, functions are the function values, pred is the predicate set, goal is the goal state, object is the object set, domain is the action model, params are the action parameters, pos_prec is the precondition, adds are the addition effects, dels are the deletion effects. Creating a dictionary structure to store the parsing results according to the specified format can systematically and structurally integrate the heterogeneous information such as domain rules, state descriptions, and action models scattered in the PDDL file, forming a unified and easily accessible data organization form. This dictionary structure clearly delineates core modules such as metrics, predicate definitions, instance information (including initial state, target state, and object set), and domain actions (including parameters, preconditions, added effects, and deleted effects) through hierarchical key-value pairs. This enables the rapid location and retrieval of key planning elements such as initial state, target state, and action model, avoiding the problems of scattered information searching and cumbersome associations in traditional file parsing. At the same time, the standardized dictionary format provides a unified data interface for sub-goal extraction during subsequent goal decomposition, object and relationship association during dependency graph construction, state and action matching during sub-problem generation, and information transmission during LLM interaction. This ensures the efficiency and accuracy of data flow between each step, reduces the redundant overhead caused by data format conversion, and lays a solid data foundation for the smooth execution of the entire planning process.

[0027] Furthermore, in step 2, the target state The splitting rule is: split the target state All predicates are categorized by predicate name, with each predicate serving as a sub-target. Sub-targets corresponding to the same type of predicate Grouping predicates into the same subset of sub-goals enables the structured and modular decomposition of complex goals, laying the foundation for subsequent dependency analysis and ordered planning. First, each predicate is treated as an independent sub-goal. First, it can decompose complex target states containing multiple relationships into several independent units with uniform granularity and clear semantics, avoiding the difficulty of planner solving caused by the high overall complexity of the target. Second, the method of classifying and grouping sub-targets by predicate name can accurately filter out sub-targets with similar semantic relationships. For example, in the Blocks domain, all "ON" predicates correspond to the stacking relationship between objects, ensuring that subsequent dependency graph construction only focuses on semantically related sub-targets, avoiding invalid association analysis between unrelated sub-targets, and improving the accuracy and efficiency of dependency determination. At the same time, this decomposition rule has strong universality and standardization, and is not limited by specific domains. Whether it is object stacking planning in the Blocks domain or other complex planning scenarios with predicate descriptions, the goal can be standardizedly decomposed according to this rule, providing a consistent input format for the unified construction and topological sorting of subsequent directed acyclic dependency graphs, ensuring the smoothness and scalability of the entire planning process.

[0028] Furthermore, in step 3, the specific method for constructing the directed acyclic dependency graph is as follows: [The text abruptly ends here, likely due to an incomplete sentence or a formatting error.] The objects involved are treated as nodes, and the sub-targets are in the form of directed binary tuples. Treated as directed edges, sub-targets Represents a node Pointing to node traverse all sub-targets The constructed directed acyclic dependency graph transforms the implicit dependencies between sub-objectives into an intuitive and quantifiable graphical structure, providing solid support for determining a reasonable solution order in subsequent topological sorting. This construction method accurately captures the strong coupling relationships between sub-objectives; for example, in the Blocks domain, the edges corresponding to sub-objectives (ONBA) are... The edge corresponding to the sub-target (ONCB) By traversing all sub-goals to construct a dependency graph, the dependency logic of "complete first (ONBA) then execute (ONCB)" can be clearly presented, avoiding the subjectivity and blindness of sub-goal order determination in traditional methods. At the same time, the directed acyclic graph structure is naturally adapted to topological sorting algorithms, which can systematically output conflict-free and efficient sub-goal execution sequences, eliminating planning failures or efficiency losses caused by improper execution order of sub-goals from the root. Moreover, this construction method does not rely on specific domain knowledge and can achieve generalized construction based solely on the directed binary form of sub-goals, ensuring the adaptability and reliability of the method in various complex structural planning scenarios.

[0029] Furthermore, in step 3, the topological sorting is performed based on the dependencies between sub-goals, specifically for edges existing in the directed acyclic dependency graph. The corresponding sub-target The execution order takes precedence over all others. Sub-targets of the target node This method can systematically determine the optimal solution order for sub-objectives, fundamentally avoiding conflicts or planning failures between sub-objectives due to improper execution order. The sorting precisely follows the strong coupling logic between sub-objectives. For example, in the Blocks domain, the sub-objective corresponding to edge B→A (ONBA) takes precedence over the sub-objective corresponding to edge C→B with B as the target node (ONCB). That is, "Block B on Block A" must be completed before "Block C on Block B" can be executed, ensuring that the execution of preceding sub-objectives does not violate the preconditions of subsequent sub-objectives and avoiding the invalid operation of reworking and adjusting the preceding state after the execution of subsequent sub-objectives. Simultaneously, this dependency-based topological sorting automatically generates a conflict-free ordered sequence of sub-objectives without manual intervention. This solves the problem of difficult-to-determine subtask order in traditional hierarchical decomposition methods and improves the consistency and reliability of the sorting results through explicit priority rules, providing crucial guarantees for the recursive solution of subsequent sub-problems and the orderly merging of sub-plans, thereby improving the efficiency and legitimacy of the overall planning.

[0030] Furthermore, in step 4, the specific process of recursively traversing the ordered sub-target sequence to generate sub-problems is as follows: Preset an instance template where both the initial state and the target state are empty, and traverse the ordered sub-target sequence. The currently traversed sub-targets As the target state and the current state This initial state is written into the instance template, forming a subproblem. This approach enables standardized, modular construction and ordered solution of subproblems, ensuring the consistency and controllability of the planning process. A pre-defined, unified empty instance template provides a standardized structural framework for subproblems, avoiding planner adaptation issues caused by inconsistent formatting of factor problems. By writing the currently traversed sub-goal as the target state and the current state as the initial state into the template, each subproblem focuses on achieving a single sub-goal. This reduces the solution complexity of individual subproblems and ensures consistency between the solution of subproblems and the order of sub-goals through recursive traversal. For example, in the Blocks domain, this can be achieved by following an ordered sequence of sub-goals. When generating subproblems, the solution to the previous subproblem is directly used as the initial state of the next subproblem, ensuring that sub-goals are achieved step by step in the order of dependency. At the same time, this generation method achieves a close connection between subproblems and the overall planning process. The solution to each subproblem can update the current state in real time and pass it to the next round of traversal. This not only ensures that sub-goals do not interfere with each other, but also lays the foundation for the orderly merging of subsequent sub-plans, greatly improving the efficiency and reliability of the overall planning.

[0031] Furthermore, in mode A of step 5, the prompts passed to the LLM include a domain world model description, which is consistent with the constraints of the action model M, and is used to guide the LLM to select actions that meet the preconditions from the executable action sequence A. This ensures the legality and validity of LLM output actions, avoiding the problem of unexecutable actions due to the lack of domain constraints in existing LLM heuristic guidance methods. The domain world model description accurately maps the core constraints such as preconditions and action effects in the action model M. Combined with the executable action sequence A, it is input into the LLM, allowing the LLM to fully understand the rule boundaries of the current planning scenario, such as the preconditions for action execution and restrictions on object interaction. It also guides the LLM to select actions within the legal action range, preventing the output of invalid actions that exceed domain rules or do not meet preconditions. For example, in the Blocks domain, the domain world model description clearly states the constraint that "the picking action must satisfy the condition that the robotic arm is idle and the object is in a clean state." Guided by this description, the LLM selects actions from... When selecting an action from the executable action sequence, the constraint is automatically applied, avoiding the selection of actions that do not conform to the scenario rules. At the same time, this constraint-based prompt design makes the LLM selection more targeted, focusing on effective actions that fit the current state and the target state, further compressing the planner's search space, improving the efficiency of solving sub-problems, and ensuring that the LLM auxiliary process plays a heuristic guiding role without affecting the reliability of the overall planning.

[0032] Furthermore, in mode B of step 5, the prompts passed to the LLM include domain-specific indicators, which are used to guide the LLM to generate intermediate states that conform to domain constraints. and intermediate state Key predicates and target states The predicate types are related.

[0033] Furthermore, step 6, after merging the sub-plans, includes a verification step: the overall plan π is input into the verifier. Based on the preconditions and subsequent effects of the action model M, the verifier checks the legality and state reachability of each action in the overall plan π and outputs the verification results. By examining each action in the overall plan to see if it meets the preconditions, whether the state transition after the action execution conforms to the subsequent effects of the action model M, and whether the target state can be successfully reached from the initial state through a complete action sequence, the verifier can accurately identify potential problems such as "the execution of a preceding sub-plan destroys the preconditions of subsequent actions" or "an action exceeds the constraints of domain rules." For example, if the merged sub-plan results in "the robotic arm performing a picking action without meeting the idle condition," the verifier can promptly detect and output abnormal results, preventing the planning scheme from failing in actual execution. Simultaneously, this verification step further enhances the credibility of the overall plan, compensates for the lack of a terminal verification mechanism in some existing planning methods, ensures the output overall plan has complete executability, provides a solid guarantee for its implementation in subsequent practical application scenarios, and reduces execution risks and resource consumption caused by plan defects.

[0034] Furthermore, in mode A of step 5, if consecutive If the planner still fails to solve the problem after the LLM is called to select an action and update the current state, it switches to mode B to continue processing the subproblem. ,in Select the maximum number of times for the preset action. By dynamically switching LLM-assisted strategies, flexibility and efficiency in solving sub-problems are achieved, avoiding the bottleneck of a single mode. Mode A selects actions from the sequence of executable actions using LLM to compress the search space, suitable for scenarios where the search domain slightly exceeds the planner's capacity but the local action direction is clear; however, when continuous... If the problem remains unsolved after several actions, it indicates that the complexity of the subproblem cannot be alleviated by a single action selection, and there may be issues with long path planning or deep state relationships. In this case, switch to the appropriate mode. By using LLM to predict intermediate states and breaking down atomic problems into two smaller subproblems, the complexity of the problem can be simplified at its root, overcoming the limitations of single-action selection. This adaptive switching mechanism fully leverages the advantages of mode A in rapidly oriented and compressing the search space, while also utilizing the problem-breaking capabilities of mode B to handle more complex subproblem scenarios. This avoids the time wastage caused by continuous ineffective attempts in a single mode, ensuring that the LLM-assisted process can flexibly adjust its strategy based on the actual solution of the subproblems, thereby improving the success rate and efficiency of solving subproblems and even the overall planning. Attached Figure Description

[0035] Figure 1Flowcharts for two methods of applying LLM to complex problem planning;

[0036] Figure 2 A flowchart illustrating the process of breaking down a problem and recursively solving its subproblems;

[0037] Figure 3 A comparison chart of two application models for LLM-involved planning; Detailed Implementation

[0038] Example 1

[0039] As attached Figure 1-3 As shown, the solution to the large-scale planning problem based on the general knowledge of a large language model includes the following steps:

[0040] Step 1. Parsing and Modeling: Receive the PDDL domain file and instance file, and parse them to obtain the initial state. Target state and motion models The target state Composed of several sub-objectives Composition, sub-targets The form is an ordered pair;

[0041] Step 2. Target Decomposition: Decompose the target state Decompose into several sub-objectives in the form of directed binary tuples All sub-targets Insert into the preprocessing sequence;

[0042] Step 3. Dependency Graph Construction and Sorting: Based on Sub-goals in the Preprocessed Sequence Construct a directed acyclic dependency graph A topological sort is performed on the directed acyclic dependency graph to obtain an ordered sequence of sub-targets. ;

[0043] Step 4. Subproblem generation and solution: Recursively traverse the ordered sub-target sequence, and sort the sub-targets in order. Loading subproblem subproblems satisfy ,in This represents the initial state of the subproblem, which is also the current state. The planner is then invoked to solve the subproblem. If the planning is successful, a sub-plan will be obtained. Proceed to step 6; if it fails or times out, proceed to step 5.

[0044] Step 5. Utilize Large Language Model (LLM) to reduce the search domain and simplify the complexity of subproblems through two application modes, specifically including the following two application modes:

[0045] Mode A: Invoke LLM to select an action from the sequence of executable actions, compressing the search space. The specific process is as follows:

[0046] A1. Obtain the executable action sequence: Pass the current state to the successor generator. And the action model M, the successor generator outputs an executable action sequence. The core implementation logic of the successor generator is as follows: traverse all actions in the action model M, and check whether the preconditions of each action are consistent with the current state. The predicates in the code are matched exactly, and all actions that meet the preconditions are selected to form an executable action sequence. And output;

[0047] A2.LLM selects the next action: Passes the current state to the LLM. Target state Given an executable action sequence A, the LLM selects an action from the executable action sequence A. And return;

[0048] A3. Update the current state: Input the current state into the state converter. and actions The core implementation logic of the state converter is: parsing actions. The "adds" and "dels" effects defined in the action model M affect the current state. Perform a "delete-add" operation (delete the predicate specified in dels, add the predicate specified in adds), and output the updated current state. Return to step 4 to continue solving the subproblem. ;

[0049] Mode B: Invoke LLM to predict intermediate states and break down sub-problems. The specific process is as follows:

[0050] B1. Obtaining intermediate states: Passing the current state to the LLM and target state LLM returns to an intermediate state intermediate state It consists of 1-2 key predicates;

[0051] B2. Generating new subproblems: Constructing intermediate subproblems and ; This is the first sub-problem in the middle of the split. This is the second sub-problem that has been split in the middle;

[0052] B3. Obtaining the solution path for the new problem: Calling the planner to calculate intermediate subproblems. Action path If the planning is successful, the action path will be executed. If the planning fails, return to step B1 to retrieve the intermediate state again. ;

[0053] B4. Update the current state: Input the current state into the state converter. and action path The state converter's processing logic for the action path is as follows: according to the action order in the action path, it sequentially parses the "add effect" and "delete effect" of each action, gradually updates the current state, and finally outputs the updated current state. Return to step 4 to continue solving the subproblem. ;

[0054] Step 6. Sub-plan merging: Merge all sub-plans Generate the overall plan by concatenating the ordered sub-objective sequences in sequence. .

[0055] Step 6. Sub-plan merging and verification:

[0056] Sub-plan merging: merge all sub-plans Generate the overall plan by concatenating the ordered sub-objective sequences in sequence. ;

[0057] Overall plan verification: Input the overall plan π into the verifier. The core implementation logic of the verifier is: from the initial state... Begin by executing and verifying each action in the sequence of the overall plan π: 1. Verify whether the preconditions of the current action completely match the current state; 2. Update the state according to the effect of the action model; 3. After all actions are executed, verify whether the final state matches the target state. Consistency. If any step fails the verification, output the specific error message; if all verifications pass, the overall plan is confirmed to be legal and reachable.

[0058] First, the system receives the PDDL domain file and instance file and parses them to obtain the initial state, target state, and action model. The target state is then decomposed into several sub-objectives in the form of directed binary tuples, and a preprocessing sequence is constructed. Next, a directed acyclic dependency graph (DADGs) is built based on the dependencies between sub-objectives. A topological sort is used to determine the ordered sub-objective sequence, fundamentally solving the problem of disordered sub-objective order. Then, the ordered sub-objective sequence is recursively traversed, and each sub-objective and the current state are packaged into a subproblem and solved using the planner. If the solution fails or times out, the solution process is optimized using two constrained LLM application modes: In Mode A, the process proceeds sequentially from the initial state to the next state. The algorithm outputs the executable action sequence in the current state, then passes the current state, target state, and action sequence to the LLM, constraining the LLM to select legal actions. After the state converter updates the current state, the algorithm is solved again, achieving directional compression of the search space. In mode B, the current state and target state are passed to the LLM, constraining it to return an intermediate state composed of 1-2 key predicates. Based on this, the atomic problem is split into two smaller sub-problems. The planner solves the new sub-problems to obtain action paths and updates the current state, achieving hierarchical simplification of complex problems. Finally, all sub-plans are concatenated according to the ordered sub-target sequence to generate the overall planning scheme.

[0059] Compared to existing technologies, which either lack a systematic decomposition and sorting mechanism or rely on manual or experience-based methods to determine the order of subtasks, this solution achieves automatic and reasonable determination of the order of sub-objectives through directed binary tuple decomposition and directed acyclic dependency graph topological sorting. For example, in the Blocks domain, the target state { It can be automatically split into ordered sub-target sequences { }>{ }>{ }, where the above expression is the standard predicate expression of the PDDL planning domain definition language, which is common in the field of intelligent planning. The binary predicate defined for PDDL is used to represent the stacking state of block x placed on block y. The overall target state corresponding to this set of expressions is: block C stacked on block B, block D stacked on block C, and block B stacked on block A. This avoids the efficiency loss caused by invalid solution order and greatly improves planning efficiency. Existing end-to-end LLM planning methods directly generate complete action sequences from the model, lacking explicit constraints on domain rules (such as action preconditions and object interaction constraints). This easily leads to the output of actions that do not meet the execution prerequisites (such as generating a "pick-up action" without satisfying "robotic arm is idle") or invalid actions that are outside the domain scope, resulting in the inability to guarantee the legality of actions. Existing heuristic guidance methods only guide LLM to provide search direction through general prompts, without considering domain-specific constraints (such as action preconditions and object interaction constraints). Integrating effects and state transition rules into the guiding logic also presents problems such as conflicts between output actions and domain rules, and lack of execution feasibility. This solution ensures the reliability of LLM output through two constrained modes: Mode A constrains LLM to select actions from the sequence of executable actions, eliminating the output of actions that do not meet the preconditions; Mode B limits the intermediate state to 1-2 key predicates, reducing the difficulty of LLM reasoning and ensuring the validity of the intermediate state. For example, when the current state is {(ONTABLEC),(ONTABLEA),(ONTABLEB),(ONTABLED)} and the target state is {(ONCB),(ONDC),(ONBA)}, LLM returns to the intermediate state (ONBA), splitting the original problem into two easily solvable subproblems, significantly reducing the search space. Existing technologies struggle to balance search efficiency and result validity. This solution, through a comprehensive "split-sort-restricted assistance-merge" design, leverages traditional planners to ensure action validity and state reachability while overcoming the bottleneck of state space explosion through LLM assistance. Furthermore, it is decoupled from existing planners, exhibiting strong versatility and scalability. Moreover, the combination of ordered planning among sub-goals and restricted LLM assistance ensures the validity of the overall plan without complex conflict resolution after sub-plan merging. For example, when multiple sub-plans are chained together, the execution results of preceding sub-plans do not violate the preconditions of subsequent sub-plans, significantly reducing the verification cost and execution risk of the overall plan.

[0060] In step 1, when parsing the PDDL domain file and instance file, a dictionary structure is created to store the parsing results. The dictionary structure is as follows: {'metric':XXX,'pred':['on',['object','object']]...,'instance':{'init':{'functions':XXX,'pred':XXX},'goal':XXX,'object':XXX,},'domain':{'pick-up':{'params':XXX,'pos_prec':XXX,'adds':XXX,'dels':} XXX}…}}, where metric is the metric, pred is the predicate definition, instance-init is the initial state, functions are the function values, pred is the predicate set, goal is the goal state, object is the object set, domain is the action model, params are the action parameters, pos_prec are the preconditions, adds are the addition effects, dels are the deletion effects. A dictionary structure is created according to the specified format to store the parsing results. It can systematically and structurally integrate the heterogeneous information such as domain rules, state descriptions, and action models scattered in the PDDL file to form a unified and easily accessible data organization form. This dictionary structure clearly delineates core modules such as metrics, predicate definitions, instance information (including initial state, target state, and object set), and domain actions (including parameters, preconditions, added effects, and deleted effects) through hierarchical key-value pairs. This enables the rapid location and retrieval of key planning elements such as initial state, target state, and action model, avoiding the problems of scattered information searching and cumbersome associations in traditional file parsing. At the same time, the standardized dictionary format provides a unified data interface for sub-goal extraction during subsequent goal decomposition, object and relationship association during dependency graph construction, state and action matching during sub-problem generation, and information transmission during LLM interaction. This ensures the efficiency and accuracy of data flow between each step, reduces the redundant overhead caused by data format conversion, and lays a solid data foundation for the smooth execution of the entire planning process.

[0061] In step 2, the target state The splitting rule is as follows: classify all predicates in the target state G according to their predicate names, and treat each predicate as a sub-target. Sub-targets corresponding to the same type of predicate Grouping predicates into the same subset of sub-goals enables the structured and modular decomposition of complex goals, laying the foundation for subsequent dependency analysis and ordered planning. First, each predicate is treated as an independent sub-goal. First, it can decompose complex target states containing multiple relationships into several independent units with uniform granularity and clear semantics, avoiding the difficulty of planner solving caused by the high overall complexity of the target. Second, the method of classifying and grouping sub-targets by predicate name can accurately filter out sub-targets with similar semantic relationships. For example, in the Blocks domain, all "ON" predicates correspond to the stacking relationship between objects, ensuring that subsequent dependency graph construction only focuses on semantically related sub-targets, avoiding invalid association analysis between unrelated sub-targets, and improving the accuracy and efficiency of dependency determination. At the same time, this decomposition rule has strong universality and standardization, and is not limited by specific domains. Whether it is object stacking planning in the Blocks domain or other complex planning scenarios with predicate descriptions, the goal can be standardizedly decomposed according to this rule, providing a consistent input format for the unified construction and topological sorting of subsequent directed acyclic dependency graphs, ensuring the smoothness and scalability of the entire planning process.

[0062] In step 3, the specific method for constructing the directed acyclic dependency graph is as follows: Objects involved in the target state G are treated as nodes, and sub-targets are in the form of directed binary tuples. Treated as directed edges, sub-targets Represents a node Pointing to node traverse all sub-targets The constructed directed acyclic dependency graph transforms the implicit dependencies between sub-objectives into an intuitive and quantifiable graphical structure, providing solid support for determining a reasonable solution order in subsequent topological sorting. This construction method accurately captures the strong coupling relationships between sub-objectives. For example, in the Blocks domain, sub-objective (ONBA) corresponds to edge B→A, and sub-objective (ONCB) corresponds to edge C→B. By traversing all sub-objectives to construct the dependency graph, the dependency logic of "complete (ONBA) first, then execute (ONCB)" can be clearly presented, avoiding the subjectivity and blindness of sub-objective order determination in traditional methods. At the same time, the directed acyclic graphical structure is naturally adapted to the topological sorting algorithm, and can systematically output conflict-free and efficient sub-objective execution sequences, fundamentally eliminating planning failures or efficiency losses caused by improper execution order of sub-objectives. Furthermore, this construction method does not rely on specific domain knowledge and can achieve generalized construction based solely on the directed binary form of sub-objectives, ensuring the adaptability and reliability of the method in various complex structural planning scenarios.

[0063] In step 3, the topological sorting is performed based on the dependencies between sub-goals. For edges in a directed acyclic dependency graph, < The corresponding sub-target The execution order takes precedence over all others. Sub-targets of the target node This method can systematically determine the optimal solution order for sub-objectives, fundamentally avoiding conflicts or planning failures between sub-objectives due to improper execution order. The sorting precisely follows the strong coupling logic between sub-objectives. For example, in the Blocks domain, the sub-objective corresponding to edge B→A (ONBA) takes precedence over the sub-objective corresponding to edge C→B with B as the target node (ONCB). That is, "Block B on Block A" must be completed before "Block C on Block B" can be executed, ensuring that the execution of preceding sub-objectives does not violate the preconditions of subsequent sub-objectives and avoiding the invalid operation of reworking and adjusting the preceding state after the execution of subsequent sub-objectives. Simultaneously, this dependency-based topological sorting automatically generates a conflict-free ordered sequence of sub-objectives without manual intervention. This solves the problem of difficult-to-determine subtask order in traditional hierarchical decomposition methods and improves the consistency and reliability of the sorting results through explicit priority rules, providing crucial guarantees for the recursive solution of subsequent sub-problems and the orderly merging of sub-plans, thereby improving the efficiency and legitimacy of the overall planning.

[0064] In step 4, the specific process of recursively traversing the ordered sub-target sequence to generate sub-problems is as follows: Preset an instance template where both the initial state and the target state are empty, and traverse the ordered sub-target sequence. The currently traversed sub-targets As the target state and the current state This initial state is written into the instance template, forming a subproblem. It can achieve standardized and modular construction and orderly solution of sub-problems, ensuring the continuity and controllability of the planning process. A pre-defined, unified empty instance template provides a standardized structural framework for subproblems, avoiding planner adaptation issues caused by inconsistent formatting of factor problems. By writing the currently traversed sub-goal as the target state and the current state as the initial state into the template, each subproblem focuses on achieving a single sub-goal. This reduces the complexity of solving individual subproblems and ensures consistency between the order of subproblem solving and sub-goal sorting through recursive traversal. For example, in the Blocks domain, when generating subproblems according to the ordered sub-goal sequence {(ONBA)}->{(ONCB)}->{(ONDC)}, the solution to the previous subproblem directly serves as the initial state for the next subproblem, ensuring that sub-goals are achieved step-by-step in a dependent order. Simultaneously, this generation method achieves close integration between subproblems and the overall planning process. The solution to each subproblem updates the current state in real time and propagates it to the next round of traversal, ensuring that sub-goals do not interfere with each other and laying the foundation for the orderly merging of subsequent sub-plans, significantly improving the efficiency and reliability of the overall planning.

[0065] In step 5, mode A, the prompts passed to the LLM include a domain world model description, which is consistent with the constraints of the action model M. This description guides the LLM to select actions from the executable action sequence A that meet the preconditions. This ensures the legality and validity of the actions output by the LLM, avoiding the problem of actions being unexecutable due to the lack of domain constraints in existing LLM heuristic guidance methods. The domain world model description accurately maps the core constraints such as preconditions and action effects in the action model M. Combined with the executable action sequence A, it is fed into the LLM, allowing the LLM to fully understand the rule boundaries of the current planning scenario, such as the preconditions for action execution and the restrictions on object interaction. It also guides the LLM to select within the legal action range, preventing the output of invalid actions that exceed the domain rules or do not meet the preconditions. For example, in the Blocks domain, the domain world model description clearly states the constraint that "the picking action must satisfy the condition that the robotic arm is idle and the object is in a clean state." Under the guidance of this description, when the LLM selects an action from the executable action sequence {(pick-upb),(pick-upc),(pick-upa),(pick-upd)}, it will automatically fit this constraint, avoiding the selection of actions that do not conform to the scene rules. Meanwhile, this constraint-based cue design makes LLM selection more targeted, enabling it to focus on effective actions that fit the current state and the target state, further compressing the planner's search space, improving the efficiency of solving sub-problems, and ensuring that the LLM auxiliary link plays a heuristic guiding role without affecting the reliability of the overall planning.

[0066] In step 5, mode B, the prompts passed to the LLM include domain-specific indicators, which are used to guide the LLM to generate intermediate states that conform to domain constraints. and intermediate state Key predicates and target states The predicate types are related.

[0067] In step 6, after merging the sub-plans, a verification step is also included: the overall plan π is input into the verifier. Based on the preconditions and subsequent effects of the action model M, the verifier verifies the legality and state reachability of each action in the overall plan π and outputs the verification results. By examining each action in the overall plan to see if it meets the preconditions, whether the state transition after the action execution conforms to the subsequent effects of the action model M, and whether the target state can be successfully reached from the initial state through a complete action sequence, the verifier can accurately identify potential problems such as "the execution of a preceding sub-plan destroys the preconditions of subsequent actions" or "an action exceeds the constraints of domain rules." For example, if the merged sub-plan results in "the robotic arm performing a picking action without meeting the idle condition," the verifier can promptly detect and output abnormal results, preventing the planning scheme from failing in actual execution. Simultaneously, this verification step further strengthens the credibility of the overall plan, compensates for the lack of a terminal verification mechanism in some existing planning methods, ensures the output overall plan has complete executability, provides a solid guarantee for its implementation in subsequent practical application scenarios, and reduces execution risks and resource consumption caused by plan defects.

[0068] In step 5, mode A, if continuous If the planner still fails to solve the problem after the LLM is called to select an action and update the current state, it switches to mode B to continue processing the subproblem. ,in With a preset maximum number of action selections (k≥1), the LLM-assisted strategy is dynamically switched to achieve flexibility and efficiency in solving sub-problems, avoiding bottlenecks in solving single modes. Mode A uses LLM to select actions from the sequence of executable actions to compress the search space, suitable for scenarios where the search domain slightly exceeds the planner's capacity but the local action direction is clear. However, if a solution cannot be found after k consecutive action selections, it indicates that the complexity of the sub-problem cannot be alleviated by a single action selection, and there may be problems with long path planning or deep state associations. At this point, switching to Mode B, which uses LLM to predict intermediate states, splits the atomic problem into two smaller sub-problems, simplifying the problem complexity from the root and overcoming the limitations of single action selection. This adaptive switching mechanism fully leverages the advantages of Mode A in quickly and directionally compressing the search space, while also utilizing the problem splitting capability of Mode B to handle more complex sub-problem scenarios. It avoids the time loss caused by continuous ineffective attempts in a single mode, ensuring that the LLM-assisted stage can flexibly adjust its strategy according to the actual solution situation of the sub-problems, improving the success rate and efficiency of solving sub-problems and even the overall planning.

[0069] This implementation takes the Blocks domain (block stacking planning scenario) as an example.

[0070] Detailed Explanation of Implementation Steps

[0071] Step 1: Analytical Modeling

[0072] The core of this step is to receive the PDDL domain file and instance file, parse them, and extract the initial state. The target state G and action model M are defined, and the parsing results are stored in a standardized dictionary structure.

[0073] Input file description

[0074] PDDL domain file: Defines the action rules of the Blocks domain, including action names (such as pick-up, stack, unstack, put-down), action parameters, preconditions (pos_prec), add effects (adds), delete effects (dels), etc. For example, the precondition of the "stack action" is "the robotic arm holds block A and the top of block B is empty", the add effect is "block A is on block B", and the delete effect is "the robotic arm holds block A and the top of block B is empty".

[0075] PDDL instance file: Defines the initial state, target state, and set of objects involved in a specific planning task. For example, in this embodiment, the set of objects is {block A, block B, block C, block D, desktop Table}. Initial state The target state G is {(ONTABLEA),(ONTABLEB),(ONTABLEC),(ONTABLED),(HANDEMPTY)} (all blocks are on the table, the robotic arm is idle), and the target state G is {(ONCB),(ONDC),(ONNBA),(HANDEMPTY)} (block D is on C, C is on B, B is on A, the robotic arm is idle).

[0076] Implementation of the parsing process

[0077] A parsing script was written in Python, using a PDDL parsing library such as pddlpy to parse the domain file and instance file. The specific process is as follows:

[0078] Extract the metrics, predicate definitions, and action models from the domain file: the predicates include "ONTABLE(x)" (block x is on the table), "ON(x,y)" (block x is on block y), "HANDEMPTY" (robotic arm is idle), "HOLDING(x)" (robotic arm holds block x), and "CLEAR(x)" (block x is empty at the top); the action models are stored in the structure of "action name - parameter - precondition - add effect - delete effect".

[0079] Extract the initial state (init), goal state (goal), and object set (object) from the instance file: the initial state contains the initial predicate set and function values, the goal state contains the goal predicate set, and the object set is all entities involved in the planning.

[0080] Step 2: Target Decomposition

[0081] The core of this step is to decompose the target state G into several sub-targets in the form of directed binary tuples. And preprocessing sequences are constructed according to predicate names.

[0082] 2.1 Implementation of Splitting Rules

[0083] Based on the decomposition rules of the target state G, all predicates in the target state are classified according to their names, and each predicate is treated as a sub-target. Sub-targets corresponding to the same type of predicate are grouped into the same subset of sub-targets. In this embodiment:

[0084] The predicates of the target state G include “ON(C,B)”, “ON(D,C)”, “ON(B,A)”, and “HANDEMPTY”, where “ON” type predicates are core stacked targets and “HANDEMPTY” are auxiliary targets.

[0085] Sub-targets are obtained by splitting according to the rules: =(ON,C,B) =(ON,D,C) =(ON,B,A) =(HANDEMPTY), where , , Classified into the "ON" sub-target subset. It can be used as a separate auxiliary sub-target.

[0086] Constructing the preprocessed sequence: [ , , , ], auxiliary sub-target It will not participate in dependency graph construction at this time, but will be ensured to be satisfied during the final merge.

[0087] Sub-objective formal specification

[0088] All sub-goals are represented as directed tuples. For predicates of the type “ON(x,y)”, the tuple is (x,y), which represents the directed relation “x is on y”. For parameterless predicates (such as “HANDEMPTY”), the tuple is (∅,HANDEMPTY), which represents a state goal without any association between objects.

[0089] Step 3: Dependency Graph Construction and Sorting

[0090] The core of this step is to construct directed acyclic dependency graphs (DADGs) based on the sub-targets in the preprocessed sequence, and obtain an ordered sub-target sequence through topological sorting.

[0091] Construction and implementation of directed acyclic dependency graph

[0092] Treating the objects (blocks A, B, C, and D) involved in the target state G as nodes, and the sub-targets in the form of directed binary tuples. Treated as directed edges, sub-targets Represents a node Pointing to node Traverse all sub-targets to build the dependency graph:

[0093] Sub-target =(ON,C,B) corresponds to the edge C→B (meaning that the state related to B must be processed before C can be placed on B).

[0094] Sub-target =(ON,D,C) corresponds to the edge D→C (meaning that the state related to C must be processed before D can be placed on C);

[0095] Sub-target =(ON,B,A) corresponds to the edge B→A (meaning that the state related to A must be processed before B can be placed on A);

[0096] After traversing all sub-goals, a directed acyclic dependency graph is constructed: D→C→B→A.

[0097] Topological sorting implementation

[0098] Topological sorting is performed based on the dependencies between sub-goals. For edges existing in a directed acyclic dependency graph (...), ... ), corresponding sub-targets The execution order takes precedence over all others. Sub-targets of the target node In this embodiment:

[0099] Sub-objectives corresponding to edge D→C Prioritizes the sub-objectives corresponding to edge C→B ;

[0100] Sub-target corresponding to edge C→B Prioritizes the sub-objectives corresponding to edge B→A ;

[0101] Auxiliary sub-targets (HANDEMPTY) needs to be executed after all stacked sub-targets are completed (i.e., to ensure that the robot arm is finally idle), so it is placed at the end of the sequence after sorting.

[0102] The final ordered sub-target sequence is obtained: [ =(ON,B,A), =(ON,C,B), =(ON,D,C), =(HANDEMPTY)].

[0103] Step 4: Subproblem generation and solution

[0104] The core of this step is to recursively traverse the ordered sub-objective sequence, generate standardized sub-problems, and call the planner to solve them. If the solution fails or times out, proceed to step 5.

[0105] 4.1 Sub-problem generation and implementation

[0106] Given an instance template with an empty initial state and target state, it iterates through the ordered sequence of sub-targets, using the currently traversed sub-target as the target state and the current state. This initial state is written into the instance template, forming a subproblem. :

[0107] Initial current state (All blocks are on the table, the robotic arm is idle);

[0108] Traverse the first sub-target Generating subproblems The goal is to "implement D on C";

[0109] like Solution successful. Update after executing subplan. Then iterate through the second sub-target. Generating subproblems The goal is to "achieve C on B"; recursively traverse all sub-goals to generate corresponding sub-problems.

[0110] Planner Invocation Implementation

[0111] We selected the existing mature planners FastDownward and LAMA, and used a Python script to call the planners to solve the subproblems:

[0112] Subproblems The instance template is converted into a PDDL problem file that the planner can recognize;

[0113] Input the domain file (the domain model obtained from step 1) and the problem file into the planner, and set the solution timeout;

[0114] If the planner returns a valid sequence of actions (sub-plan) within the timeout period... If the solution is successful, proceed to step 6; if the planner returns no solution or times out without returning a result, proceed to step 5.

[0115] Step 5: LLM-constrained auxiliary optimization

[0116] The core of this step is to use two constrained application modes to reduce the search domain or simplify the complexity of subproblems through LLM, thereby ensuring successful subproblem solving. In this embodiment, DeepSeek-R1 is selected as the LLM component, and interaction is achieved through an API interface.

[0117] 5.1 Mode A: LLM selects actions to compress the search space (suitable for scenarios with a large search space but clearly defined executable actions).

[0118] Assume subproblems initial state Sub-target state The planner call timed out, so we'll optimize using Mode A:

[0119] A1. Obtain the executable action sequence

[0120] Pass the current state to the successor generator Given the action model M, the successor generator selects executable actions in the current state based on the preconditions of the action model M.

[0121] initial state The conditions "ONTABLE(A), CLEAR(A), HANDEMPTY" are met, therefore "pick-up(A)" can be executed;

[0122] Similarly, "pick-up(B)", "pick-up(C)", and "pick-up(D)" all satisfy the preconditions;

[0123] The successor generator outputs an executable action sequence Actions=[pick-up(A),pick-up(B),pick-up(C),pick-up(D)].

[0124] A2.LLM Select Next Action

[0125] Pass the prompt word and current state to the LLM Target state And the executable action sequence A, with prompts containing a description of the domain world model (consistent with the constraints of the action model M), such as the Blocks domain example, prompt template: 'Current domain rules: 1. The pick-up action must satisfy the conditions that the robotic arm is idle (HANDEMPTY) and the top of the object is empty (CLEAR); 2. The stack action must satisfy the conditions that the robotic arm holds an object (HOLDING) and the top of the target object is empty (CLEAR); Current state: Target state: G, Executable action sequence: A, Please select the legal action from the sequence that is closest to the target.

[0126] LLM, based on domain constraints and goal orientation, selects the optimal action from the executable action sequence A and returns the result: (pick-up(B)) (because the goal is "B is on A", B must be picked first).

[0127] A3. Update the current status

[0128] Input the current state to the state converter and actions The state converter updates the state based on the addition and deletion effects of the "pick-up" action in the action model M:

[0129] Deletion result: Removes "ONTABLE(B)", "CLEAR(B)", and "HANDEMPTY";

[0130] Add effect: Add "HOLDING(B)";

[0131] Updated current status =[ONTABLE(A),ONTABLE(D),ONTABLE(C),CLEAR(A),CLEAR(D),CLEAR(C),HOLDING(B)];

[0132] Return to step 4, to Given the initial state, resolve the subproblem. .

[0133] 5.2 Mode B: LLM predicts intermediate states by decomposing them into subproblems (suitable for scenarios where subproblems are highly complex and cannot be alleviated by a single action choice).

[0134] Assuming pattern A is called k=3 times consecutively (with a preset maximum number of action selections k=3), the subproblems... Still no solution found. Switch to Mode B for optimization.

[0135] B1. Obtain intermediate state

[0136] Pass the prompt word and current state to the LLM and sub-target state =(ON,B,A), the prompt contains domain-specific indicators, guiding the LLM to generate an intermediate state consisting of 1-2 keywords.

[0137] LLM, based on domain knowledge and goal orientation, returns to an intermediate state. (Key predicate: The top of block A is empty, which lays the foundation for subsequent stacking of block B on top of block A).

[0138] B2. Generate new subproblems

[0139] Based on the intermediate state Construct two new subproblems:

[0140] intermediate subproblem Initial state intermediate state That is, "to make the top of block A empty" (in the current initial state, A is already CLEAR, so this subproblem can be solved directly).

[0141] intermediate subproblem Initial state Sub-target state That is, "to place B on top of A, provided that the top of A is empty".

[0142] B3. Obtaining a solution path for a new problem

[0143] Call the planner to solve intermediate subproblems :

[0144] Due to the initial state The condition "CLEAR(A)" has been met, and the planner returns the action path. The solution was successful;

[0145] If the planner returns no solution, return to step B1 and pass the prompt word to the LLM again to obtain a new intermediate state. (e.g., [HOLDING(B)]).

[0146] B4. Update the current state

[0147] Input the current state to the state converter and action path The state converter outputs the updated current state. The state remains unchanged because no action was taken.

[0148] Return to step 4, to Given the initial state, resolve the original subproblem. At this point, the complexity of the subproblem decreases, and the planner can quickly solve for the sub-plan. .

[0149] 5.3 Logic for switching between two modes

[0150] The switching between mode A and mode B is based on the preset maximum number of action selections, k. This embodiment The value can be configured from 1 to 5 based on the complexity of the subproblems, and can be automatically switched via a Python script:

[0151] Set the counter count=0, and increment count by 1 after each execution of step A3 in mode A;

[0152] like And since the subproblem has not yet been solved, continue executing mode A;

[0153] like If the subproblem is still not solved, the counter is reset to 0, and the system switches to mode B.

[0154] If the planner solves in mode B If it fails, repeat steps B1-B3. The number of retries and other parameters are configurable. k=1-5, number of retries=2-3 times. If it still fails, it is determined that the subproblem has no solution and a planning failure message is output.

[0155] Step 6: Sub-plan merging and verification

[0156] All sub-plans The overall plan π is generated by concatenating the ordered sub-objective sequences in sequence. π is then input into the verifier, which verifies the legality and state reachability of each action based on the preconditions and subsequent effects of the action model M, and outputs the verification results.

[0157] 6.1 Sub-plans to be merged and implemented

[0158] Traverse the ordered sequence of sub-goals and concatenate the sub-plans corresponding to each sub-goal in sequence:

[0159] Sub-target Sub-project (Implement B on A);

[0160] implement Then, the current state is updated to [ONTABLE(A),ONTABLE(D),ONTABLE(C),ON(B,A),CLEAR(C),CLEAR(B),CLEAR(D),HANDEMPTY];

[0161] Sub-target Sub-project (Implement C on B);

[0162] implement Then, the current state is updated to [ONTABLE(A),ONTABLE(D),ON(C,B),ON(B,A),CLEAR(D),CLEAR(C),HANDEMPTY];

[0163] Sub-target Sub-project (Implement D on C);

[0164] implement Then, the current state is updated to [ONTABLE(A),ON(B,A),ON(C,B),ON(D,C),CLEAR(D),HANDEMPTY];

[0165] Sub-target Sub-project (No additional action is required; the current state already satisfies HANDEMPTY.)

[0166] Merge all sub-plans to generate the overall plan. .

[0167] 6.2 Verification Steps Implementation

[0168] The overall plan π is input into the validator, which verifies the legality and state reachability of each action based on the preconditions and subsequent effects of the action model M.

[0169] Verifier execution process: from initial state Begin by executing each action in the overall plan sequentially, checking whether the preconditions are met before each action is executed, and whether the state transition after execution conforms to the addition / deletion effect;

[0170] Example verification:

[0171] Action pick-up(D): Before execution, the state satisfies "ONTABLE(D), CLEAR(D), HANDEMPTY" (preconditions). After execution, "HOLDING(D)" is added to the state, and "ONTABLE(D), CLEAR(D), HANDEMPTY" is removed (to achieve the desired effect).

[0172] Action stack(D,C): Before execution, the state satisfies “HOLDING(D), CLEAR(C)” (preconditions). After execution, the state adds “ON(D,C), CLEAR(D), HANDEMPTY” and removes “HOLDING(D), CLEAR(C)” (to achieve the desired effect).

[0173] Verify all actions in sequence. The final state is [ONTABLE(A),ON(B,A),ON(C,B),ON(D,C),CLEAR(D),HANDEMPTY], which is consistent with the target state G.

[0174] Verification result output: If all actions are legal and the final state is consistent with the target state, output "Planning successful, overall plan is legal and reachable"; if there are actions that do not meet the preconditions or the state is unreachable, output specific error information, such as "CLEAR(B) was not satisfied before action stack(C,B) was executed", and return to step 5 to re-optimize the corresponding sub-problem.

Claims

1. A method for solving large-scale planning problems based on general knowledge of a large language model, characterized in that: Includes the following steps: Step 1. Parsing and Modeling: Receive the PDDL domain file and instance file, and parse them to obtain the initial state. Target state and motion models The target state Composed of several sub-objectives Composition, sub-targets The form is an ordered pair; Step 2. Target Decomposition: Decompose the target state Decompose into several sub-objectives in the form of directed binary tuples All sub-targets Insert into the preprocessing sequence; Step 3. Dependency Graph Construction and Sorting: Based on Sub-goals in the Preprocessed Sequence Construct a directed acyclic dependency graph A topological sort is performed on the directed acyclic dependency graph to obtain an ordered sequence of sub-targets. ; Step 4. Subproblem generation and solution: Recursively traverse the ordered sub-target sequence, and sort the sub-targets in order. Loading subproblem subproblems satisfy ,in This represents the initial state of the subproblem, which is also the current state. The planner is then invoked to solve the subproblem. If the planning is successful, a sub-plan will be obtained. Proceed to step 6; if it fails or times out, proceed to step 5. Step 5. Utilize a Large Language Model (LLM) to reduce the search domain and simplify the complexity of subproblems. The LLM includes two application modes: Mode A selects actions from a sequence of executable actions to compress the search space, and Mode B predicts intermediate states to break down subproblems. After optimization by the LLM, return to Step 4 to continue solving the subproblems. ; Step 6. Sub-plan merging: Merge all sub-plans Generate the overall plan by concatenating the ordered sub-objective sequences in sequence. ; In step 3, the topological sorting is performed based on the dependencies between sub-goals, for edges existing in the directed acyclic dependency graph ( The corresponding sub-target The execution order takes precedence over all others. Sub-targets of the target node ; Mode A in step 5 includes the following process: A1. Obtain the executable action sequence: Pass the current state to the successor generator. And the action model M, the successor generator outputs an executable action sequence. ; A2.LLM selects the next action: Passes the current state to the LLM. Target state Given an executable action sequence A, the LLM selects an action from the executable action sequence A. And return; A3. Update the current state: Input the current state into the state converter. and actions The state converter outputs the updated current state. Return to step 4 to continue solving the subproblem. ; In Mode A, the prompts passed to the LLM include a domain world model description, which is consistent with the action model. The constraints are consistent and are used to guide the LLM to select actions that meet the preconditions from the executable action sequence A. ; The mode of step 5 In the middle, if continuous If the planner still fails to solve the problem after the LLM is called to select an action and update the current state, then the process switches to mode 4. Continue processing subproblems ,in Select the maximum number of times for the preset action. .

2. The method for solving large-scale planning problems based on general knowledge of a large language model according to claim 1, characterized in that, In step 1, when parsing the PDDL domain file and instance file, a dictionary structure is created to store the parsing results.

3. The method for solving large-scale planning problems based on general knowledge of a large language model according to claim 1, characterized in that, In step 2, the target state The splitting rule is: split the target state All predicates are categorized by predicate name, with each predicate serving as a sub-target. Sub-targets corresponding to the same type of predicate They are grouped into the same sub-target subset.

4. The method for solving large-scale planning problems based on general knowledge of a large language model according to claim 1, characterized in that, In step 3, the specific method for constructing the directed acyclic dependency graph is as follows: [The text abruptly ends here, likely due to an incomplete sentence or a formatting error.] The objects involved are treated as nodes, and the sub-targets are in the form of directed binary tuples. Treated as directed edges, sub-targets Represents a node Pointing to node traverse all sub-targets A directed acyclic dependency graph is constructed.

5. The method for solving large-scale planning problems based on general knowledge of a large language model according to claim 1, characterized in that, In step 4, the specific process of recursively traversing the ordered sub-target sequence to generate sub-problems is as follows: Preset an instance template where both the initial state and the target state are empty, and traverse the ordered sub-target sequence. The currently traversed sub-targets As the target state and the current state This initial state is written into the instance template, forming a subproblem. .

6. The method for solving large-scale planning problems based on general knowledge of a large language model according to claim 1, characterized in that, The specific process of mode B in step 5 includes the following steps: B1. Obtaining intermediate states: Passing the current state to the LLM and target state LLM returns to an intermediate state intermediate state It consists of 1-2 key predicates; B2. Generating new subproblems: Constructing intermediate subproblems and ; This is the first sub-problem in the middle of the split. This is the second sub-problem that has been split in the middle; B3. Obtaining the solution path for the new problem: Calling the planner to calculate intermediate subproblems. Action path If the planning is successful, the action path will be executed. If the planning fails, return to step B1 to retrieve the intermediate state again. ; B4. Update the current state: Input the current state into the state converter. and action path The state converter outputs the updated current state. Return to step 4 to continue solving the subproblem. In step 5, mode B, the prompts passed to the LLM include domain-specific indicators, which guide the LLM to generate intermediate states that conform to domain constraints. And intermediate state Key predicates and sub-objectives The predicate types are related.

7. The method for solving large-scale planning problems based on general knowledge of a large language model according to claim 1, characterized in that, In step 6, after merging the sub-plans, a verification step is also included: the overall plan π is input into the verifier, and the verifier verifies the action model. Preconditions and subsequent effects, verify the overall plan Verify the legality and reachability of each action, and output the verification result.

Images