# Errors are Useful Prompts: Instruction Guided Task Programming
with Verifier-Assisted Iterative Prompting

Marta Skreta∗1,2, Naruki Yoshikawa∗1,2, Sebastian Arellano-Rubach3, Zhi Ji1,
Lasse Bjørn Kristensen1,
Kourosh Darvish1,2, Alán Aspuru-Guzik1,2, Florian Shkurti1,2, Animesh
Garg1,2,4 ∗ Authors contributed equally, 1University of Toronto, 2Vector
Institute, 3University of Toronto Schools, 4NVIDIAEmail:
<EMAIL_ADDRESS><EMAIL_ADDRESS>
###### Abstract

Generating low-level robot task plans from high-level natural language
instructions remains a challenging problem. Although large language models
have shown promising results in generating plans, the accuracy of the output
remains unverified. Furthermore, the lack of domain-specific language data
poses a limitation on the applicability of these models. In this paper, we
propose CLAIRify, a novel approach that combines automatic iterative prompting
with program verification to ensure programs written in data-scarce domain-
specific language are syntactically valid and incorporate environment
constraints. Our approach provides effective guidance to the language model on
generating structured-like task plans by incorporating any errors as feedback,
while the verifier ensures the syntactic accuracy of the generated plans. We
demonstrate the effectiveness of CLAIRify in planning chemistry experiments by
achieving state-of-the-art results. We also show that the generated plans can
be executed on a real robot by integrating them with a task and motion
planner.

##  I Introduction

Leveraging natural language instruction to create a plan comes naturally to
humans. However, when a robot is instructed to do a task, there is a
communication barrier: the robot does not know how to convert the natural
language instructions to lower-level actions it can execute, and the human
cannot easily formulate lower-level actions. Large language models (LLMs) can
fill this gap by providing a rich repertoire of common sense reasoning to
robots [1, 2].

Recently, there has been impressive progress in using LLMs [3, 1, 4] for
problems involving structured outputs, including code generation [5, 6, 7] and
robot programming [8]. These code generation models are often trained on code
that is widely available on the Internet and perform well in few-shot settings
for generating code in those languages. However, to employ LLMs for task-plan
generation there are two main issues to address: (1) lack of task-plan
verification and (2) poor performance for data-scarce domain-specific
languages.

#### Lack of task plan verification

Task plans generated by LLMs, often, cannot be executed out-of-the-box with
robots. There are two reasons for that. First, machine-executable languages
are bound by strict rules [9]. If the generated task plan does not adhere to
them, it will not be executable. Hence, we need a way to verify the syntactic
correctness of the structured task plan. Second, LLMs might generate a task
plan that looks reasonable (i.e. is syntactically correct) but is not actually
executable by a robot. Avoiding this problem requires information about the
world state and robot capabilities, as well as general reasoning about the
physical world [10].

#### Data scarcity for domain-specific languages

It is difficult for LLMs to generate task plans in a zero-shot manner for
domain-specific languages (DSLs), such as those in chemistry and physics
because there is significantly less data on the Internet for those specific
domains, so LLMs are unable to generalize well with no additional information
[11, 12]. It is possible to address this by fine-tuning models on pairs of
natural-language inputs and structured-language outputs, but it is very
difficult to acquire training datasets large enough for the model to learn a
DSL reasonably well [13], and there is a large computation cost for fine-
tuning LLMs [14]. However, it has been shown that LLMs can adapt to new
domains with effective prompting [15]. Our insight is to leverage the in-
context ability of an LLM by providing the rules of a structured language as
input, to generate a plan according to the template of the target DSL.

Figure 1: Task plans generated by LLMs may contain syntactical errors in
domain-specific languages. By using verifier-assited iterative prompting,
CLAIRify can generate a valid program, which can be executed by a robot.

In this work, we propose to address the verification and data-scarcity
challenges. We introduce CLAIRify 111CLAIRify website: https://ac-
rad.github.io/clairify/, a framework that translates natural language into a
domain-specific structured task plan using an automated iterative verification
technique to ensure the plan is syntactically valid in the target DSL (Figure
1) by providing the LLM a description of the target language. Our model also
takes into account environment constraints if provided. The generated
structured-language-like output is evaluated by our verifier, which checks for
syntax correctness and for meeting environment constraints. The syntax and
constraint errors are then fed back into the LLM generator to generate a new
output. This iterative interaction between the generator and the verifier
leads to grounded syntactically correct target language plans.

We evaluate the capabilities of CLAIRify using a domain-specific language
called Chemical Description Language (XDL) [16] as the target structured
language unfamiliar to the LLM. XDL is an XML-based DSL to describe action
plans for chemistry experiments in a structured format, and can be used to
command robots in self-driving laboratories [17]. Converting experiment
descriptions to a structured format is nontrivial due to the large variations
in the language used. Our evaluations show that CLAIRify outperforms the
current state-of-the-art XDL generation model in [16]. We also demonstrate
that the generated plans are executable by combining them with an integrated
task and motion planning (TAMP) framework and running the corresponding
experiments in the real world. Our contributions are:

  * •

We propose a framework to produce task plans in a DSL using an iterative
interaction of an LLM-based generator and a rule-based verifier.

  * •

We show that the interaction between the generator and verifier improves zero-
shot task plan generation.

  * •

Our method outperforms the existing XDL generation method in an evaluation by
human experts.

  * •

We integrate our generated plans with a TAMP framework, and demonstrate the
successful translation of elementary chemistry experiments to a real robot
execution.

##  II Related work

###  II-A Task Planning

High-level task plans are often generated from a limited set of actions [9],
because task planning becomes intractable as the number of actions and time
horizon grows [18]. One approach to do task planning is using rule-based
methods [16, 19]. More recently, it has been shown that models can learn task
plans from input task specifications [20, 21, 22], for example using
hierarchical learning [23, 24], regression based planning [25], reinforcement
learning [26]. However, to effectively plan task using learning-based
techniques, large datasets are required that are hard to collect in many real-
world domains. Our approach, on the other hand, generates a task plan directly
from an LLM in a zero-shot way on a constrained set of tasks which are
directly translatable to robot actions. We ensure that the plan is
syntactically valid and meets environment constraints using iterative error
checking.

###  II-B Task Planning with Large Language Models

Recently, many works have used LLMs to translate natural language prompts to
robot task plans [10, 27, 8, 2]. For example, Inner Monologue [27] uses LLMs
in conjunction with environment feedback from various perception models and
state monitoring. However, because the system has no constraints, it can
propose plans that are nonsensical. SayCan [10], on the other hand, grounds
task plans generated by LLMs in the real world by providing a set of low-level
skills the robot can choose from. A natural way of generating task plans is
using code-writing LLMs because they are not open-ended (i.e. they have to
generate code in a specific manner in order for it to be executable) and are
able to generate policy logic. Several LLMs trained on public code are
available, such as Codex [5], CodeT5 [6], AlphaCode [7] and CodeRL [28]. LLMs
can be prompted in a zero-shot way to generate task plans. For example, Code
as Policies [8] repurposes code-writing LLMs to write robot policy code and
ProgPrompt [2] generates plans that take into account the robot’s current
state and the task objectives. However, these methods generate Pythonic code,
which is abundant on the Internet. For DSLs, naive zero-shot prompting is not
enough; the prompt has to incorporate information about the target language so
that the LLM can produce outputs according to its rules.

###  II-C Leveraging Language Models with External Knowledge

A challenge with LLMs generating code is that the correctness of the code is
not assured. There have been many interesting works on combining language
models with external tools to improve the reliability of the output. Mind’s
Eye [12] attempts to ground large language model’s reasoning with physical
simulation. They trained LLM with pairs of language and codes and used the
simulation results to prompt an LLM to answer general reasoning questions.
Toolformer [29] incorporates API calls into the language model to improve a
downstream task, such as question answering, by fine-tuning the model to learn
how to call API. LEVER [30] improves LLM prompting for SQL generation by using
a model-based verifier trained to verify the generated programs. As SQL is a
common language, the language model is expected to understand its grammar.
However, for DSLs, it is difficult to acquire training datasets and expensive
to execute the plans to verify their correctness. Our method does not require
fine-tuning any models or prior knowledge on the target language within the
language model. Our idea is perhaps closest to LLM-Augmenter [31], which
improves LLM outputs by giving it access to external knowledge and
automatically revising prompts in natural language question-answering tasks.
Our method similarly encodes external knowledge in the structure of the
verifier and prompts, but for a structured and formally verifiable domain-
specific language.

Figure 2: System overview: The LLM takes the input (1), structured language
definition, and (optionally) resource constraints and generates unverified
structured language (2). The output is examined by the verifier, and is passed
to LLM with feedback (3). The LLM-generated outputs passes through the
verifier (4). The correct output (5) is passed to the task and motion planner
to generate robot trajectories. The robot executes the planned trajectory (6).

##  III Task Programming with CLAIRify

####  CLAIRify Overview

We present a system that takes as input the specifications of a structured
language (i.e. all its rules and permissible actions) as well as a task we
want to execute written in natural language and outputs a syntactically
correct task plan. A general overview of the CLAIRify pipeline is in Figure 2.
We combine input instruction and language description into a prompt and pass
the prompt into the structured language generator (here we use GPT-3 [1], a
large language model). However, we cannot guarantee the output from the
generator is syntactically valid, meaning that it would definitely fail to
compile into lower-level robot actions. To generate syntactically valid
programs, we pass the output of the generator through a verifier. The verifier
determines whether the generator output follows all the rules and
specifications of the target structured language and can be compiled without
errors. If it cannot, the verifier returns error messages stating where the
error was found and what it was. This is then appended to the generator output
and added to the prompt for the next iteration. This process is repeated until
a valid program is obtained, or until the timeout condition is reached (if
that happens, an error is thrown for the user). Algorithm 1 describes of our
proposed method.

Once the generator output passes through the verifier with no errors, we are
guaranteed that it is syntactically valid structured language. This program
can then be translated into lower-level robot actions by passing through TAMP
for robot execution. Each component of the pipeline is described in more
detail below.

####  CLAIRify in Chemistry Lab Automation

While our pipeline can in theory be applied to any structured language, we
demonstrate it using the chemical description language (XDL) [16] as an
example of a structured language. XDL describes the hardware and reagents to
be used in the experiment, and the experimental procedures in chronological
order. Note that chemistry proceures are not well standardized; there is a lot
of variation, and so translating them to a structured plan that can be
executed by a robot is nontrivial [32].

###  III-A Generator

The generator takes a user’s instruction and generates structured-language-
like output using a large language model (LLM) using a description of the
structured language. The input prompt skeleton is shown in Snippet 1, Figure
3. The description of the XDL language includes its file structure and lists
of the available actions (can be thought of as functions), their allowed
parameters and their documentation.

Although the description of the target structured language information is
provided, the candidate task plan is not guaranteed to be syntactically
correct (hence we refer to is as “structured-language-like”). To ensure the
syntactical correctness of the generated code, the generator is iteratively
prompted by the automated interaction with the verifier. The generated code is
passed through the verifier, and if no errors are generated, then the code is
syntactically correct. If errors are generated, we re-prompt the LLM with the
incorrect task plan from the previous iteration along with the list of errors
indicating why the generated steps were incorrect. The skeleton of the
iterative prompt is shown in Snippet 2, Figure 3. Receiving the feedback from
the verifier is used by the LLM to correct the errors from the previous
iteration. This process is continued until the generated code is error-free or
a timeout condition is reached, in which case we say we were not able to
generate a task plan.

Algorithm 1 CLAIRify: Verifier-Assisted Iterative Prompts

Structured language description $\mathcal{L}$, instruction $x$

Structured language task plan, $y_{SL}$

procedure IterativePrompting($\mathcal{L}$, $x$)

$y_{SL^{\prime}}=\text{Generator}(\mathcal{L},x)$

$\text{errors}=\text{Verifier}(y_{SL^{\prime}})$

while $\text{len(errors)}>0\text{ or timeout condition != True}$ do

$y_{SL^{\prime}}=\text{Generator}(\mathcal{L},x,y_{SL^{\prime}},\text{errors})$

$\text{errors}=\text{Verifier}(y_{SL^{\prime}})$

$y_{SL}=y_{SL^{\prime}}$

###  III-B Verifier

The verifier works as a syntax checker and static analyzer to check the output
of the generator and send feedback to the generator. It first checks whether
the input can be parsed as a correct XML and then checks the allowance of
action tags, the existence of mandatory properties, and the correctness of
optional properties. This evaluates if the input is syntactically correct XDL.
It also checks the existence of definitions of hardware and reagents used in
the procedure or provided as environment constraints, which works as a simple
static analysis of necessary conditions for executability. If the verifier
catches any of these errors, the candidate task plan is considered to be an
invalid. The verifier returns a list of errors it found, which is then fed
back to the generator.

###  III-C Incorporating Environment Constraints

Because resources in a robot workspace are limited, we need to consider those
constraints when generating task plans. If specified, we include the available
resources into the generator prompt. The verifier also catches if the
candidate plan uses any resources aside from those mentioned among the
available robot resources. Those errors are included in the generator prompt
for the next iteration. If a constraint list is not provided, we assume the
robot has access to all resources. In the case of chemistry lab automation,
those resources include experiment hardware and reagents.

###  III-D Interfacing with Planner on Real Robot

In many cases, the target DSL is not embodied, and it is hardware independent.
Our verified task plan only contains high-level descriptions of actions. To
execute those actions by a robot, we need to map them to low-level actions and
motion that the robot can execute. To ensure the generated structured language
is executable by the robot, we employ a task and motion planning (TAMP)
framework. In our case, we use PDDLStream [9] to generate robot action and
motion plans simultaneously. In this process, visual perception information,
coming from the robot camera, grounds the predicates for PDDLStream, and
verified task plans are translated into problem definitions in PDDLStream.

For the chemistry lab automation domain, high-level actions in XDL are mapped
to intermediate goals in PDDLStream, resulting in a long-horizon multistep
planning problem definition. To also incorporate safety considerations for
robot execution, We use a constrained task and motion planning framework for
lab automation [33] to execute the XDL generated by CLAIRify.

⬇

initial_prompt = """

# <Description of XDL>

# <Hardware constraints(optional)>

# <Reagent constraints (optional)>

Convert to XDL:

# <Natural language instruction>

"""

Snippet 1: Initial prompt

⬇

iterative_prompt = """

# <Description of XDL>

# <Hardware constraints(optional)>

# <Reagent constraints (optional)>

Convert to XDL:

# <Natural language instruction>

# <XDL from previous iteration>

This XDL was not correct.

There were the errors

# <List of errors, one per line>

Please fix the errors

"""

Snippet 2: Iterative prompt

Figure 3: Prompt skeleton: (1) At the initial generation, we prompt the LLM
with a description of XDL and the natural language instruction. (2) After the
LLM generates structured-language-like output, we pass it through our
verifier. If there are errors in the generated program, we concatenate the
initial prompt with the XDL from the previous iteration and a list of the
errors.

##  IV Experiments and Evaluation

Our experiments are designed to evaluate the following hypotheses: i)
Automated iterative prompting increases the success rate of unfamiliar
language generation, ii) The quality of generated task plans is better than
existing methods, iii) Generated plans can be executed by actual hardware.

Table I: Comparison of our method with existing methods on the number of
successfully generated valid XDL plans and their quality on 108 organic
chemistry experiments from [34].

Dataset | Method | Number generated ↑ | Expert preference ↑
---|---|---|---
Chem-RnD | SynthReader [16] | 92/108 | 13/108
|  CLAIRify [ours] | 105/108 | 75/108
Chem-EDU | SynthReader [16] | 0/40 | -
|  CLAIRify [ours] | 40/40 | -

###  IV-A Experimental Setup

To generate XDL plans, we use text-davinci-003, the most capable GPT-3 model
at the time of writing. We chose to use this instead of code-davinci-002 due
to query and token limits.

To execute the plans in the real world, we use an altered version of Franka
Emika Panda arm robot, equipped with a Robotiq 2F-85 gripper, to handle
vessels. The robot also communicates with instruments in the chemistry
laboratory, such as a weighing scale and a magnetic stirrer. These devices are
integrated to enable pouring and stirring skills.

Figure 4: Violin plots showing distributions of different error categories in
XDL plans generated for experiments for the Chem-RnD (left) and Chem-EDU
(right) datasets. The x-axis shows the error categories and the y-axis shows
the number of errors for that category (lower is better). For the Chem-RnD
dataset, we show the error distributions for both CLAIRify and SynthReader.
Each violin is split in two, with the left half showing the number of errors
in plans generated from CLAIRify (teal) and the right half showing those from
SynthReader (navy). For the Chem-EDU dataset, we only show the distributions
for CLAIRify. In both plots, we show the mean of the distribution with a gold
dot (and the number beside in gold) and the median with a grey dot.

#### Datasets

We evaluated our method on two different datasets:

(1) Chem-RnD [Chemistry Research & Development]: This dataset consists of 108
detailed chemistry-protocols for synthesizing different organic compounds in
real-world chemistry labs, sourced from the Organic Syntheses dataset (volume
77) [34]. Due to GPT-3 token limits, we only use experiments with less than
1000 characters. We use Chem-RnD as a proof-of-concept that our method can
generate task plans for complex chemistry methods. We do not aim to execute
the plans in the real world, and so we do not include any constraints.

(2) Chem-EDU [Everyday Educational Chemistry]: We evaluate the integration of
CLAIRify with real-world robots through a dataset of 40 natural language
instructions containing only safe (edible) chemicals and that are, in
principle, executable by our robot. The dataset consists of basic chemistry
experiments involving edible household chemicals, including acid-base
reactions and food preparation procedures222CLAIRify Data & code:
https://github.com/ac-rad/xdl-generation/. When generating the XDL, we also
included environment constraints based on what equipment our robot had access
to (for example, our robot only had access to a mixing container called
“beaker").

###  IV-B Metrics and Results

The results section is organized based on the four performance metrics that we
will consider, namely: Ability to generate structured-language output, Quality
of the generated plans, Number of interventions required be the verifier, and
Robotic validation capability. We compared the performance of our method with
SynthReader, a state-of-the-art XDL generation algorithm which is based on
rule-based tagging and grammar parsing of chemical procedures [16]

(1) Ability to generate a structured language plan. First, we investigate the
success probability for generating plans. For CLAIRify, if it is in the
iteration loop for more than $x$ steps (here, we use $x=10$), we say that it
is unable to generate a plan and we exit the program. When comparing with
SynthReader, we consider that approach unable to generate a structured plan if
the SynthReader IDE (called ChemIDE333ChemIDE using XDL:
https://croningroup.gitlab.io/chemputer/xdlapp/) throws a fatal error when
asked to create a plan. For both models, we also consider them unable to
generate a plan if the generated plan only consists of empty XDL tags (i.e. no
experimental protocol). For all experiments, we count the total number of
successfully generated language plans divided by the total number of
experiments. Using this methodology, we tested the ability of the two models
to generate output on both the Chem-RnD and Chem-EDU datasets. The results for
both models and both datasets are shown in Table I. We find that out of 108
Chem-RnD experiments, CLAIRify successfully returned a plan 97% of the time,
while SynthReader returned a plan 85% of the time. For the Chem-EDU dataset,
CLAIRify generated a plan for all instructions. SynthReader was unable to
generate any plans for that dataset, likely because the procedures are
different from typical chemical procedures (they use simple action
statements). This demonstrates the generalizability of our method: we can
apply it to different language styles and domains and still obtain coherent
plans.

(2) Quality of the predicted plan (without executing the plan). To determine
if the predicted task plans actually accomplish every step of their original
instructions, we report the number of actions and parameters that do not align
between the original and generated plan, as annotated by expert experimental
chemists. To compare the quality of the generated plans between CLAIRify and
SynthReader, we ask expert experimental chemists to, given two anonymized
plans, either pick a preferred plan among them or classify them as equally
good. We also ask them to annotate errors in the plans in the following
categories: Missing action, Missing parameter, Wrong action, Wrong parameter,
Ambiguous value, Other error. Here, actions refer to high-level steps in the
procedure (e.g., <Add reagent="acetic acid"> is an action) and parameters
refer to reagents, hardware, quantities and experiment descriptors (e.g., in
<HeatChill vessel="beaker" temp="100C">, vessel and temp are both parameters).
The annotations were performed using the LightTag Text Annotation Tool [35].

#### Chem-RnD dataset

The results for the Chem-RnD dataset with respect to expert preference are
reported in the last column of Table I. We found that out of 108 experiments,
experts preferred the XDL plan generated from CLAIRify 75 times and the one
from SynthReader 13 times (the remaining 20 were considered to be of similar
quality).

The distributions of the annotated errors are shown in Figure 4. We find that
for 4 out of 6 error categories, our model does at least as well as or better
than the baseline method when considering the mean and median of the
distributions. We also find that for those categories, our method produces
more experiments with 0 errors.

One advantage of our method is that it generates less plans with missing
actions compared with the baseline. As XDL generation in SynthReader is
implemented by rule-based pattern-matching techniques, any actions that do not
match those templates would not appear in the final XDL. For example, for the
protocol:

⬇

To a solution of m-CPBA (200 mg, 0.8 mmol) in dichloromethane (10 mL), cooled
to 0 ∘C, was added dropwise a solution of 5-chloro-10-oxa-3-thia-tricyclo
[5.2.1.01, 5] dec-8-ene (150 mg, 0.8 mmol) in dichloromethane (10 mL).

the plan generated by CLAIRify was

⬇

<Add vessel="V1" reagent="m-CPBA" amount="200 mg"/>

<Add vessel="V1" reagent="dichloromethane" volume="10 mL"/>

<HeatChill vessel="V1" temp="0 ∘C" time="3 min"/>

<Add vessel="V2" reagent="5-chloro-10-oxa-3-thia-
tricyclo[5,2,1,0*1,5*]dec-8-ene" amount="150 mg"/>

<Add vessel="V2" reagent="dichloromethane" volume="10 mL"/>

<Transfer from_vessel="V2" to_vessel="V1"/>

while the plan generated from SynthReader was

⬇

<Add vessel="reactor" reagent="5-chloro-10-oxa-3-thia-tricyclo" volume="0"
speed="40.0"/>

Our model is able to decompose a complicated procedure into simpler actions by
making two solutions in separate beakers and combining them with a Transfer
procedure. It also assumes that the solutions don’t already exist as mixtures
and creates them from scratch. This is another benefit of our model, as it is
able to understand implicit actions. For example, given the prompt

⬇

L-Ornithine (31.92 g, 120 mmol) was added to a mixture of KOH (6.72 g, 120
mmol), water (200 ml) and THF (100 ml)

SynthReader considers a mixture of three chemicals as a single solution and
creates the action:

⬇

<Add vessel="reactor" reagent="a mixture of KOH (6.72 g, 120 mmol), water (200
ml) and THF (100 ml)" volume="0" speed="40.0"/>

<AddSolid vessel="reactor" reagent="L-Ornithine" mass="31.92 g"/>

On the other hand, CLAIRify correctly understand the implicit action to mix
them beforehand and generates an appropriate XDL:

⬇

<Add vessel="V1" reagent="L-Ornithine" amount="31.92 g"/>

<Add vessel="V1" reagent="KOH" amount="6.72 g"/>

<Add vessel="V1" reagent="Water" amount="200 ml"/>

<Add vessel="V1" reagent="THF" amount="100 ml"/>

Table II: Verifier Analysis. We report the average number of times CLAIRify
calls the verifier for the experiments in a given dataset, as well as the
minimum and maximum number of times. We also report the type of error
encountered by the verifier and the number of times it caught that type.

Dataset | Average num. | Max/min |  Error type caught by verifier [count]
---|---|---|---
| verifier calls | verifier calls |
Chem-RnD | $2.58\pm 2.00$ | 10/1 |  \- missing property in action [306]
\- property not allowed [174]
\- wrong tag [120]
\- action does not exist [21]
\- item not defined in Hardware or Reagents list [15]
\- plan cannot be parsed as XML [6]
Chem-EDU | $1.15\pm 0.45$ | 3/1 |  \- item not defined in Hardware or Reagents list [47]
\- property not allowed [26]
\- wrong tag [40]
\- missing property in action [3]

However, our model produced plans with a greater number of wrong actions than
SynthReader. This is likely because our model is missing domain knowledge on
certain actions that need to be included in the prompt or verifier. For
example, given the instruction "Dry solution over magnesium sulfate", our
model inserts a <Dry .../> into the XDL plan, but the instruction is actually
referring to a procedure where ones passes the solution through a short
cartridge containing magnesium sulphate, which seems to be encoded in
SynthReader. Another wrong action our model performs is reusing vessels. In
chemistry, one needs to ensure a vessel is uncontaminated before using it.
However, our model generates plans that can use the same vessel in two
different steps without washing it in between. Our model also sometimes
generates plans with ambiguous values. For example, many experiment
descriptions include conditional statements such as “Heat the solution at the
boiling point until it becomes white”. Conditions in XDL need a numerical
condition as a parameter. Our model tries to incorporate them by including
actions such as <HeatChill temp="boiling point" time="until it becomes
white"/>, but they are ambiguous. We can make our model better in the future
by incorporating more domain knowledge into our structured language
description and improving our verifier with real-world constraints. For
example, we can incorporate visual feedback from the environment, include
look-up tables for common boiling points, and ensure vessels are not reused
before cleaning.

Despite the XDL plans generated by our method containing errors, we found that
the experts placed greater emphasis on missing actions than ambiguous or wrong
actions when picking the preferred output, indicating larger severity of this
class of error for the tasks and outputs investigated here.

Table III: Number of XDL plans successfully generated for different error
message designs in the iterative prompting scheme on a validation set from
Chem-RnD.

Variations of Iterative Prompt Design using Verifier Error Messages |  Plan’s generated success rate (%) ↑
---|---
Naive: XDL from previous iteration and string “This XDL was not correct. Please fix the errors.” |  0
Last Error: Error List from verifier from previous iteration |  30
All Errors cumulative: Accumulated error List from all previous iterations |  50
XDL + Last Error: XDL and Error List from verifier from previous iteration |  100

Figure 5: Feedback loop between the Generator and Verifier. The input text is
converted to structured-like language via the generator and is then passed
through the verifier. The verifier returns a list of errors (marked with a
yellow 1). The feedback is passed back to the generator along with the
erroneous task plan, generating a new task plan. Now that previous errors were
fixed and the tags could be processed, new errors were found (including a
constraint error that the plan uses a vessel not in the environment). These
errors are denoted with a blue 2. This feedback loop is repeated until no more
errors are caught, which in this case required 3 iterations.

#### Chem-EDU dataset

We annotated the errors in the Chem-EDU datasets using the same annotation
labels as for the Chem-RnD dataset. The breakdown of the errors is in the left
plot of Figure 4. Note that we did not perform a comparison with SynthReader
as no plans were generated from it. We find that the error breakdown is
similar to that from Chem-RnD, where we see amibiguous values in experiments
that have conditionals instead of precise values. We also encounter a few
wrong parameter errors, where the model does not include units for
measurements. This can be fixed in future work by improving the verifier to
check for these constraints.

(3) Number of interventions required by the verifier. To better understand the
interactions between the generator and verifier in CLAIRify, we analyzed the
number of interactions that occur between the verifier and generator for each
dataset to understand the usefulness of the verifier. In Table II, we show
that each experiment in the Chem-RnD dataset runs through the verifier on
average 2.6 times, while the Chem-EDU dataset experiments runs through it 1.15
times on average. The difference between the two datasets likely exists
because the Chem-EDU experiments are shorter and less complicated. The top
Chem-EDU error encountered by the verifier was that an item in the plan was
not define in the Hardware or Reagents list, mainly because we included
hardware constraints for this dataset that we needed to match in our plan. In
Figure 5, we show a sample loop series between the generator and verifier.

(4) Robotic validation (Chem-EDU only). To analyze how well our system
performs in the real world, we execute a few experiments from the Chem-EDU
dataset on our robot. Three experiments from the Chem-EDU dataset were
selected to be executed.

#### Solution Color Change Based on pH

As a basic chemistry experiment, we demonstrated the color change of a
solution containing red cabbage juice. This is a popular introductory
demonstration in chemistry education, as the anthocyanin pigment in red
cabbage can be used as a pH indicator [36]. We prepared red cabbage solution
by boiling red cabbage leaves in hot water. The colour of the solution is dark
purple/red. Red cabbage juice changes its color to bright pink if we add an
acid and to blue if we add a base, and so we acquired commercially-available
vinegar (acetic acid, an acid) and baking soda (sodium bicarbonate, a base).

In this experiment, we generated XDL plans using CLAIRify from two language
inputs:

⬇

[1] Add 40 g of red cabbage solution into a beaker. Add 10 g of acetic acid
into the beaker, then stir the solution for 10 seconds.

⬇

[2] Add 40 g of red cabbage solution into a beaker. Add 10 g of baking soda
into the beaker, then stir the solution for 10 seconds.

Figure 6 shows the flow of the experiment. Our generated a XDL plan that
correctly captured the experiment; the plan was then passed through TAMP to
generate a low-level action plan and was then executed by the robot.

Figure 6: Robot execution: The robot executes the motion plan generated from
the XDL for given natural language input. (a) CLAIRify converts the natural
language input from the user into XDL. (b) The robot interprets XDL and
performs the experiment. Stirring is done by a rotating stir bar inside the
beaker.

#### Kitchen Chemistry

We then tested whether our robot could execute a plan generated by our model
for a different application of household chemistry: food preparation. We
generated a plan using CLAIRify for the following lemonade beverage, which can
be viewed on our website:

⬇

Add 15 g of lemon juice and sugar mixture to a cup containing 30 g of
sparkling water. Stir vigorously for 20 sec.

###  IV-C Ablation Studies

We assess the impact of various components in our prompt designs and feedback
messaging from the verifier. We performed these tests on a small validation
set of 10 chemistry experiments from Chem-RnD (not used in the test set) and
report the number of XDL plans successfully generated (i.e., was not in the
iteration loop for $x=10$ steps).

#### Prompt Design

To evaluate the prior knowledge of the GPT-3 on XDL, we first tried prompting
the generator without a XDL description, i.e., with the input:

⬇

initial_prompt = """

Convert to XDL:

# <Natural language instruction>"""

The LLM was unable to generate XDL for any of the inputs from the small
validation set that contains 10 chemistry experiments. For most experiments,
when asked to generated XDL, the model output a rephrased version of the
natural language input. In the best case, it output some notion of structure
in the form of S-expressions or XML tags, but the outputs were very far away
from correct XDL and were not related to chemistry. We tried the same
experiment with code-davinci-002; the outputs generally had more structure but
were still nonsensical. This result suggests the LLM does not have the
knowledge of the target language and including the language description in the
prompt is essential to generate an unfamiliar language.

#### Feedback Design

We experimented with prompts in our iterative prompting scheme containing
various levels of detail about the errors. The baseline prompt contains a
description as well as natural language instruction. We wanted to investigate
how much detail is needed in the error message for the generator to be able to
fix the errors in the next iteration. For example, is it sufficient to write
“There was an error in the generated XDL", or do we need to include a list of
errors from the verifier (such as “Quantity is not a permissible attribute for
the Add tag"), or do we also need to include the erroneous XDL from the
previous iteration?

We find that including the erroneous XDL from the previous iteration and
saying why it was wrong resulted in the high number of successfully generated
XDL plans. Including a list of errors was better than only writing “This XDL
was not correct. Please fix the rrors", which was not informative enough to
fix any errors. Including the erroneous XDL from the previous iteration is
also important; we found that including only a list of the errors without the
context of the XDL plan resulted in low success rates.

##  V Conclusion and Future Work

In this paper, we introduce CLAIRify to generate structured language task
plans in a DSL by providing an LLM with a description of the language in a
zero-shot manner. We also ensure that the task plan is syntactically correct
in the DSL by using a verifier and iterative prompting. Finally, we show that
our plans can incorporate environmental constraints. We evaluated the
performance of CLAIRify on two datasets and find that our method was able to
generate better plans than existing baselines. Finally, we translate a select
number of these plans to real-world robot demonstrations.

In the future, we will incorporate feedback from the robot planner and
environment into our plan generation process. We will also improve the
verifier to encode knowledge of the target domain nuances. With these
technical refinements, we expect our system can become integrated even better
in robotic task planning for different domains.

##  VI Acknowledgements

We would like to thank members of the Matter Lab for annotating task plans. We
would also like to thank the Acceleration Consortium for their generous
support, as well as the Carlsberg Foundation.

## References

  * [1] T. Brown, _et al._ , “Language models are few-shot learners,” _Adv. Neural. Inf. Process. Syst._ , vol. 33, pp. 1877–1901, 2020.
  * [2] I. Singh, _et al._ , “Progprompt: Generating situated robot task plans using large language models,” in _IEEE Int. Conf. Robot. Autom._ , 2023.
  * [3] J. Devlin, _et al._ , “BERT: Pre-training of deep bidirectional transformers for language understanding,” in _North American Chapter of the Association for Computational Linguistics_ , 2019.
  * [4] A. Chowdhery, _et al._ , “PaLM: Scaling language modeling with pathways,” _arXiv:2204.02311_ , 2022.
  * [5] M. Chen, _et al._ , “Evaluating large language models trained on code,” _arXiv:2107.03374_ , 2021.
  * [6] Y. Wang, _et al._ , “CodeT5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation,” _arXiv:2109.00859_ , 2021.
  * [7] Y. Li, _et al._ , “Competition-level code generation with alphacode,” _Science_ , vol. 378, no. 6624, pp. 1092–1097, 2022.
  * [8] J. Liang, _et al._ , “Code as policies: Language model programs for embodied control,” _arXiv:2209.07753_ , 2022.
  * [9] C. R. Garrett, _et al._ , “PDDLStream: Integrating symbolic planners and blackbox samplers via optimistic adaptive planning,” in _Proc. ICAPS Conf._ AAAI Press, 2020, pp. 440–448.
  * [10] M. Ahn, _et al._ , “Do As I Can, Not As I Say: Grounding language in robotic affordances,” _arXiv:2204.01691_ , 2022.
  * [11] Y. Gu, _et al._ , “Domain-specific language model pretraining for biomedical natural language processing,” _ACM Trans. Comput. Healthcare_ , vol. 3, no. 1, pp. 1–23, 2021.
  * [12] R. Liu, _et al._ , “Mind’s eye: Grounded language model reasoning through simulation,” _arXiv:2210.05359_ , 2022.
  * [13] S. Wang, _et al._ , “Want to reduce labeling cost? GPT-3 can help,” in _Proc. EMNLP Conf._ , 2021, pp. 4195–4205.
  * [14] N. Bannour, _et al._ , “Evaluating the carbon footprint of NLP methods: a survey and analysis of existing tools,” in _SustaiNLP_ , Nov. 2021, pp. 11–21.
  * [15] S. Mishra, _et al._ , “Cross-task generalization via natural language crowdsourcing instructions,” _arXiv:2104.08773_ , 2021.
  * [16] S. H. M. Mehr, _et al._ , “A universal system for digitization and automatic execution of the chemical synthesis literature,” _Science_ , vol. 370, no. 6512, pp. 101–108, 2020.
  * [17] M. Seifrid, _et al._ , “Autonomous chemical experiments: Challenges and perspectives on establishing a self-driving lab,” _Acc. Chem. Res._ , 2022\.
  * [18] L. P. Kaelbling and T. Lozano-Pérez, “Hierarchical task and motion planning in the now,” in _IEEE Inter. Conf. Robot. Autom._ IEEE, 2011, pp. 1470–1477.
  * [19] J. A. Baier, _et al._ , “A heuristic search approach to planning with temporally extended preferences,” _Artif. Intell._ , 2009.
  * [20] P. Sharma, _et al._ , “Skill induction and planning with latent language,” _arXiv:2110.01517_ , 2021.
  * [21] S. Mirchandani, _et al._ , “ELLA: Exploration through learned language abstraction,” _Adv. Neural. Inf. Process. Syst._ , 2021.
  * [22] D. Shah, _et al._ , “Value function spaces: Skill-centric state abstractions for long-horizon reasoning,” _arXiv:2111.03189_ , 2021.
  * [23] D. Xu, _et al._ , “Neural task programming: Learning to generalize across hierarchical tasks,” in _IEEE Int. Conf. Robot. Autom._ , 2018.
  * [24] D.-A. Huang, _et al._ , “Neural Task Graphs: Generalizing to unseen tasks from a single video demonstration,” in _IEEE Comput. Vis. Pattern Recognit._ , 2019.
  * [25] D. Xu, _et al._ , “Regression planning networks,” _Adv. Neural. Inf. Process. Syst._ , vol. 32, 2019.
  * [26] B. Eysenbach, _et al._ , “Search on the replay buffer: Bridging planning and reinforcement learning,” _Adv. Neural. Inf. Process. Syst._ , vol. 32, 2019.
  * [27] W. Huang, _et al._ , “Inner monologue: Embodied reasoning through planning with language models,” _arXiv:2207.05608_ , 2022.
  * [28] H. Le, _et al._ , “CodeRL: Mastering code generation through pretrained models and deep reinforcement learning,” in _Adv. Neural. Inf. Process. Syst._ , 2022.
  * [29] T. Schick, _et al._ , “Toolformer: Language models can teach themselves to use tools,” _arXiv:2302.04761_ , 2023.
  * [30] A. Ni, _et al._ , “Lever: Learning to verify language-to-code generation with execution,” _arXiv:2302.08468_ , 2023.
  * [31] B. Peng, _et al._ , “Check your facts and try again: Improving large language models with external knowledge and automated feedback,” _arXiv:2302.12813_ , 2023.
  * [32] A. C. Vaucher, _et al._ , “Automated extraction of chemical synthesis actions from experimental procedures,” _Nat. Commun._ , 2020.
  * [33] N. Yoshikawa, _et al._ , “An adaptive robotics framework for chemistry lab automation,” _arXiv:2212.09672_ , 2022.
  * [34] H. Mehr, _et al._ , “Benchmarking results and the XDL XML schema.” 2020\. [Online]. Available: https://zenodo.org/record/3955107
  * [35] T. Perry, “LightTag: Text annotation platform,” in _Proc. EMNLP Conf._ , Nov. 2021, pp. 20–27.
  * [36] J. J. Fortman and K. M. Stubbs, “Demonstrations with red cabbage indicator,” _J. Chem. Educ._ , vol. 69, no. 1, p. 66, 1992.