eta.core.planning
The core process responsible for using schemas and memory to modify the plan.
Modifying the plan includes adding possible actions to the plan, expanding plan steps, merging plan steps, and reordering plan steps.
Notes
Currently, the plans
buffer is handled differently from the other buffers, in that we
assume it only holds one element at a time, and this element is simply replaced whenever
the plan is modified in some way.
Functions
Given a list of possible actions, attempt to add actions into the current plan. |
|
Expand a step containing a condition eventuality depending on the truth value of its condition. |
|
Attempt to expand the surface steps in the plan using one of: |
|
Expand a primitive step, i.e., one whose expansion method is supported directly. |
|
Expand a step containing a repetition eventuality depending on the truth value of its condition. |
|
Merge steps in the plan that are equivalent or unifiable. |
|
Generate a subplan for an answer step using the answer transducer. |
|
Generate a subplan for an ask step using the ask transducer. |
|
Generate a subplan for a paraphrase step using the paraphrase transducer. |
|
Generate a subplan for a react-to step using the reaction transducer. |
|
Generate a subplan for a respond-to step using the response transducer. |
|
Make modifications to the dialogue plan. |
|
Reorder steps in the plan according to imposed constraints. |
|
Generate a say-to subplan from an utterance. |
|
Generate a say-to subplan from a list of utterances. |
|
Check whether a given step wff corresponds to a dialogue schema in Eta's schema library. |
|
Split a schema step wff into the schema predicate and the arguments list for the schema. |
- planning_loop(ds)[source]
Make modifications to the dialogue plan.
First, all suggested actions are popped from the
actions
buffer, and used to create a new plan. The plan of the current dialogue state is updated, and the contents of theplans
buffer is replaced with the updated plan.- Second, this attempts to modify the plan in the
plans
buffer. This consists of the following substeps: Attempt to expand top-level steps in the plan into substeps.
Merge equivalent steps in the plan.
Reorder plan steps according to constraints.
If the plan was modified by the previous step, it is used to update the plan of the current dialogue state, and is re-added to the
plans
buffer.- Parameters:
ds (DialogueState) –
- Second, this attempts to modify the plan in the
- add_possible_actions_to_plan(actions, ds)[source]
Given a list of possible actions, attempt to add actions into the current plan.
- Parameters:
actions (list[str]) – A list of possible actions (as natural language strings or LISP-formatted S-expression strings).
ds (DialogueState) –
- Returns:
The updated plan, if successful.
- Return type:
PlanNode or None
Notes
- TODO: some possible future improvements:
For now, we assume that only the first action in a set of possible actions is used. In the future, this might be extended with a policy for attempting to add the top K possible actions.
This currently adds the action unconditionally; ultimately, the system should verify that the action can be added to the plan. This may be done by way of a pattern transducer.
The action is currently inserted as the current step, but ultimately we should be able to insert actions elsewhere in the plan as well.
- expand_plan_steps(plan, ds)[source]
- Attempt to expand the surface steps in the plan using one of:
A keyword step, which have special expansion behavior
A schema whose header matches the step WFF (unifying any schema args)
A “primitive” type of plan step whose expansion is directly supported
A pattern transduction tree mapping the step WFF to substep WFF(s)
- Parameters:
plan (PlanNode or None) – The plan to expand (if one exists).
ds (DialogueState) –
- Returns:
The updated plan, if successful.
- Return type:
PlanNode or None
Notes
- TODO: some possible future improvements:
currently, this only attempts to expand the currently due step; however, it may be possible to expand certain other steps in the plan as well.
- merge_plan_steps(plan, ds)[source]
Merge steps in the plan that are equivalent or unifiable.
- Parameters:
plan (PlanNode or None) – The plan to expand (if one exists).
ds (DialogueState) –
- Returns:
The updated plan, if successful.
- Return type:
PlanNode or None
Notes
TODO: the behavior of this function is currently hard-coded to merge directly adjacent reply-to steps in the plan. It should be generalized using a transducer that maps a plan to a new plan with merged steps, possibly making use of retrieved equivalency knowledge (allowing for, e.g., a neural network or LLM to potentially perform this step instead).
- reorder_plan_steps(plan, ds)[source]
Reorder steps in the plan according to imposed constraints.
- Parameters:
plan (PlanNode or None) – The plan to expand (if one exists).
ds (DialogueState) –
- Returns:
The updated plan, if successful.
- Return type:
PlanNode or None
Notes
TODO: this is a stub that needs implementation.
- expand_condition_step(event, ds, schema=None)[source]
Expand a step containing a condition eventuality depending on the truth value of its condition.
- Parameters:
event (Condition) – The condition eventuality to expand.
ds (DialogueState) –
schema (Schema, optional) – The schema (if any) to inherit from when instantiating the sub-eventualities.
- Returns:
The updated plan, if successful.
- Return type:
PlanNode or None
- expand_repetition_step(event, ds, schema=None)[source]
Expand a step containing a repetition eventuality depending on the truth value of its condition.
- Parameters:
event (Repetition) – The repetition eventuality to expand.
ds (DialogueState) –
schema (Schema, optional) – The schema (if any) to inherit from when instantiating the sub-eventualities.
- Returns:
The updated plan, if successful.
- Return type:
PlanNode or None
Notes
TODO: some modifications still need to be made to the method of unbinding local variables, since it may be possible that a variable within a :repeat-until section of a schema first appeared within an episode outside of the :repeat-until section, yet not within the participants list of the schema. This means that these variables will be unbound in memory following execution of the repeating episode, although typically the repetition itself still executes as intended.
- expand_primitive_step(event, ds)[source]
Expand a primitive step, i.e., one whose expansion method is supported directly.
- Parameters:
event (Eventuality) – The condition eventuality to expand.
ds (DialogueState) –
- Returns:
The updated plan, if successful.
- Return type:
PlanNode or None
- plan_paraphrase(expr, ds)[source]
Generate a subplan for a paraphrase step using the paraphrase transducer.
- Parameters:
expr (s-expr) – The wff for the paraphrase step.
ds (DialogueState) –
- Returns:
The updated plan, if successful.
- Return type:
PlanNode or None
- plan_respond(expr, ds)[source]
Generate a subplan for a respond-to step using the response transducer.
- Parameters:
expr (s-expr) – The wff for the response step.
ds (DialogueState) –
- Returns:
The updated plan, if successful.
- Return type:
PlanNode or None
- plan_answer(expr, ds)[source]
Generate a subplan for an answer step using the answer transducer.
- Parameters:
expr (s-expr) – The wff for the answer step.
ds (DialogueState) –
- Returns:
The updated plan, if successful.
- Return type:
PlanNode or None
- plan_ask(expr, ds)[source]
Generate a subplan for an ask step using the ask transducer.
- Parameters:
expr (s-expr) – The wff for the ask step.
ds (DialogueState) –
- Returns:
The updated plan, if successful.
- Return type:
PlanNode or None
- plan_react(expr, ds)[source]
Generate a subplan for a react-to step using the reaction transducer.
- Parameters:
expr (s-expr) – The wff for the react-to step.
ds (DialogueState) –
- Returns:
The updated plan, if successful.
- Return type:
PlanNode or None
- say_to_step_from_utts(utts)[source]
Generate a say-to subplan from a list of utterances.
NOTE: currently this just splits off the first utterance in the list.