This is part 2 (part 1).
Initial Idea for Plan Generation
Create a planner that can:
- Confirm that the final result structure and acceptance criteria are met.
- Respond to the calling system if some information or functionality is missing.
- Use a top-to-bottom approach and split tasks into smaller ones if necessary.
- Work with collections/lists and other data structures.
Implementation
Main points:
- The user or invoking system provides information necessary to formulate an extended version.
- The planner consists of two modules: a task manager that interacts with the user/system and a planner that creates a plan and interacts with the task manager.
Extending Task Description
The task description that is passed to the planner needs to have not only the task text but also:
- High-level values for the planner (i.e., mission, project context).
- Input information description.
- Resulting documents description.
- Acceptance criteria.
This extended description can be either the result of interaction with the user/system or generated from project description and documentation, common sense, etc.
Hierarchical Task Splitting
The start of the algorithm is almost the same as for a conventional sequential planner. The difference is the extended task description, but we can ignore it for now.
Given:
- Task as a string.
- Extended task description.
- List of available functions in the form the planner can understand.
Algorithm:
- Try to solve the task using a conventional planner and existing functions. If solved => hurrah! Done.
- Ask the planner to split the task into several (not many 5-10) stages with a detailed description (same as the extended description for the initial task) on each step.
- [Recursion]
- For each stage, try to resolve it by a conventional planner or by splitting it into smaller stages.
- If recursion works => fine!
- If not, dig down till some level.
Key points:
- Keep records of all explored steps (tree/graph of hypotheses).
- Be creative and try splitting into stages multiple times (i.e., high temperature).
- Distinguish between two problems for a solution not found (stage cannot be resolved with conventional planners):
- Cannot apply conventional planner due to a lack of functions.
- Additional information/document is required.
The main difference of the described approach from [X]_of_Thoughts approaches (CoT, ToT, GoT, etc.) is that we are okay to introduce non-defined steps and define them later, instead of doing a search only in the space of available functions.
Example A: Simple Case => Success Plan
Below is a diagram describing a simple case that is identical to a common sequential planner:
- The task is successfully split into several activities/subtasks.
- Each activity is mapped to an existing skill from the given skillset.
- The input document is mapped to the input of activity A (skill A).
- The output document is the output from the last activity C (skill C).
Example B: Simple Case => Problematic Plan
This is a more complex case:
- The planner was unable to map the initial task into a sequence of skills.
- The planner split the initial task into high-level activities.
- Activity #1 and activity #2 were successfully mapped into a sequence of skills.
- But there was a problem with activity #3 - it required additional information (document X).
- Though the planner tried to create a plan several times, document X was always required.
- This request for document X was passed to the task manager module.
Conclusion
A high-level description of the algorithm for advanced planning was given, and initial ideas were implemented.
