% Title:  ka.tex
% Submission to JAIR (?)
\documentclass[11pt]{article}
\usepackage{jair}
\usepackage{theapa}
\usepackage{graphicx}
\usepackage{float}
\newcommand{\nlg}{{\sc nlg}}
\newcommand{\nl}{{\sc nl}}
\newcommand{\ka}{{\sc ka}}
\newcommand{\ai}{{\sc ai}}
\newcommand{\etal}{{\it et al}}
\newcommand{\sumtime}{{\sc SumTime-Mousam}}
\newcommand{\stopgen}{{\sc stop}}
\newcommand{\fog}{{\sc fog}}
\newcommand{\scare}[1]{`#1'}
\newcommand{\lingform}[1]{{\em #1}}
\newcommand{\krterm}[1]{{\sc #1}}
\newcommand{\url}[1]{{\tt #1}}
\newcommand{\lineacross}{\rule{\linewidth}{1pt}}

\jairheading{18}{2003}{491-516}{11/02}{6/03}
\ShortHeadings{Acquiring Correct Knowledge for NLG}
{Reiter, Sripada, \& Robertson}
\firstpageno{491}

\begin{document}

\title{Acquiring Correct Knowledge \\for Natural Language Generation}

\author{\name Ehud Reiter \email ereiter@csd.abdn.ac.uk \\
       \name Somayajulu G. Sripada \email ssripada@csd.abdn.ac.uk \\
       \addr Department of Computing Science,\\
       University of Aberdeen, Aberdeen AB24 3UE, UK \\
       \AND
       \name Roma Robertson \email roma.robertson@ed.ac.uk \\
       \addr Division of Community Health Sciences - General Practice Section \\
       University of Edinburgh \\
       Edinburgh EH8 9DX, UK}

% For research notes, remove the comment character in the line below.
% \researchnote

\maketitle


\maketitle

\begin{abstract}
Natural language generation (\nlg{}) systems are computer software
systems that produce texts in English and other human languages, often
from non-linguistic input data.
\nlg{} systems, like most \ai{} systems, need
substantial amounts of knowledge.  However, our
experience in two \nlg{} projects suggests that it is difficult
to acquire correct knowledge for \nlg{} systems; indeed, every
knowledge acquisition (\ka{}) technique we tried had significant
problems.
In general terms, these problems were due to the complexity, novelty,
and poorly understood nature of the tasks our systems attempted, and
were worsened by the fact that people write so differently.
This meant in particular that corpus-based \ka{} approaches suffered
because it was impossible to assemble
a sizable corpus of high-quality consistent manually written texts
in our domains;
and structured expert-oriented \ka{} techniques
suffered because experts disagreed and because we could not get enough
information about special and unusual cases to build robust systems.
We believe
that such problems are likely to affect many other \nlg{} systems
as well.  In the long term, we hope that new \ka{} techniques may
emerge to help \nlg{} system builders.  In the shorter term,
we believe
that understanding how individual \ka{} techniques can fail,
and using a mixture of different \ka{} techniques with different
strengths and weaknesses, can help developers acquire \nlg{} knowledge
that is mostly correct.
\end{abstract}

\section{Introduction}

Natural language generation (\nlg{}) systems use artificial intelligence
(\ai{}) and natural language processing techniques to automatically generate
texts in English and other human languages, typically from some
non-linguistic input data \cite{Reiter:book00}.  As with most \ai{}
systems, an essential part of building an \nlg{} system is knowledge
acquisition (\ka{}), that is acquiring relevant knowledge about
the domain, the users, the language used in the texts, and so forth.

\ka{} for \nlg{} can be based on structured expert-oriented techniques,
such as think-aloud protocols and sorting, or on machine learning
and corpus analysis, which are currently very popular in other areas
of Natural Language Processing.
We have used both types of techniques in two \nlg{}
projects that included significant \ka{} efforts --
\stopgen{} \cite{Reiter:aij03}, which generated tailored smoking
cessation letters, and
\sumtime{} \cite{Sripada:es01}, which generated weather forecasts.
In both projects, and for all
techniques tried, the main problem turned out to be knowledge quality;
evaluation and validation exercises identified flaws in the knowledge
acquired using every technique.
The flaws were due to a variety of factors, but perhaps the basic underlying
reason for them was the nature of the writing tasks we were
attempting to automate.  They were:
\begin{itemize}
\item complex (as are many tasks that involve interacting
with humans): hence a lot of knowledge was needed to cover the
numerous special cases and unusual circumstances;
\item sometimes novel (not done by humans): hence sometimes there
were no experts at the task as a whole, and no existing corpora of texts
to analyse;
\item poorly understood: hence we did not have good theoretical models
to structure the knowledge being acquired, and fill in gaps in the
knowledge acquired from experts or corpora; and
\item ambiguous (allowed multiple solutions):
hence different experts and corpus
authors produced very different texts (solutions) from the same input
data.
\end{itemize}
These problems of course occur to some degree in \ka{} for other
expert system and natural language processing tasks, but we believe
they may be especially severe for \nlg{}.

We do not have a good solution for these problems, and indeed believe
that \ka{} is one of the biggest problems in applied \nlg{}.
After all, there is
no point in using \ai{} techniques to build a text-generation system
if we cannot acquire the knowledge needed by the \ai{} techniques.

In the longer term, more basic
research into \ka{} for \nlg{} is badly needed.  In the shorter term,
however, we believe that developers are more likely to acquire
correct knowledge when building an \nlg{} system if they understand likely
types of errors in the knowledge acquired from different \ka{}
techniques.  Also, to some degree the different \ka{} techniques we have
tried have complementary strengths and weaknesses; this suggests using
a variety of different techniques, so that the weaknesses of one
technique are compensated for by the strengths of other techniques.

In the remainder of this paper we give background information on
\nlg{}, \ka{}, and our systems; describe the various \ka{}
techniques we used to build our systems and the problems we
encountered; and then discuss more generally why \ka{} for \nlg{}
is difficult and how different \ka{} techniques can be combined.

\section{Background}

In this section we give some background information on natural language generation and knowledge acquistion and validation. We also introduce and briefly describe the \stopgen{} and \sumtime{} systems.

\subsection{Natural Language Generation}\label{nlg-knowledge}

Natural Language Generation is the subfield of artificial intelligence
that is concerned with automatically generating written texts in human
languages, often from non-linguistic input data.  \nlg{} systems often
have three stages \cite{Reiter:book00}:
\begin{itemize}
\item {\em Document Planning} decides on the content and structure
of the generated text; for example that a smoking-cessation letter should
start with a section that discusses the pros and cons of smoking.
%From a \ka{} perspective, this requires
%knowledge about the domain; about how domain documents are typically
%structured; and about the user and his/her
%tasks and information needs.
\item {\em Microplanning} decides on how information and structure
should be expressed linguistically; for example, that the phrase
\lingform{by mid afternoon} should be used in a weather report
to refer to the time 1500.
%From a \ka{} perspective, this requires knowledge
%about effective linguistic communication; for example, which words
%are most likely to be understood correctly by the reader, and how
%much information the reader can comfortably process in a sentence.
\item {\em Surface Realisation} generates an actual text according
to the decisions made in previous stages, ensuring that the text
conforms to the grammar of the target language (English in our systems).
%From a \ka{} perspective,
%this requires knowledge about linguistic rules, such as sentence
%grammars.
\end{itemize}
\nlg{} systems require many types of knowledge in order to carry out
these tasks.  In particular, \citeA{Kittredge:ci91} point out that \nlg{}
systems need domain knowledge (similar to that needed by expert systems),
communication knowledge (similar to that needed by other Natural Language
Processing systems), and also domain communication knowledge (DCK).
DCK is knowledge about how information in a domain is usually communicated,
including standard document structures, sublanguage grammars, and
specialised lexicons.  DCK plays a role in all aspects of language
technology (for example,
a speech recogniser will work better in a given domain if it is trained on
a corpus of texts from that domain), but it may be especially
important in \nlg{}.


\subsection{Knowledge Acquisition and Validation}

Knowledge acquisition is the subfield of artificial intelligence
that is concerned with acquiring the knowledge needed to build
\ai{} systems.  Broadly speaking the two most
common types of \ka{} techniques are:
\begin{itemize}
\item Techniques based on working with experts in a structured fashion,
such as structured
interviews, think-aloud protocols, sorting, and laddered grids
\cite{Scott:book91,Buchanan:book93}; and
\item Techniques based on learning from data sets of correct solutions
(such as text corpora);
these are currently very popular in natural language processing and
used for many different types of knowledge,
ranging from grammar rules to discourse models
(for an overview, see \citeR{Jurafsky:book00}).
\end{itemize}
There are of course other possible \ka{} techniques as well, including
directly asking experts for knowledge, and conducting scientific experiments.
Some research has been done on evaluating and comparing
\ka{} techniques, but such research can be difficult
to interpret because of methodological
problems \cite{Shadbolt:ijhcs99}.


Research has also been done on verifying and validating knowledge to check that
it is correct \cite{Adelman:book97}.  Verification techniques focus
on detecting logical anomalies and inconsistencies that often reflect
mistakes in the elicitation or coding process; we will not further discuss
these, as such errors are not our primary concern in this paper.
Validation techniques focus on detecting whether the knowledge acquired
is indeed correct and will enable the construction of a good system;
these are very relevant to efforts to detect problems in knowledge
acquired for \nlg{}.  \citeA{Adelman:book97} describe two general
types of validation techniques: (1) having experts
check the acquired knowledge and built systems, and (2) using a
library of test cases with known inputs and outputs.  In other words,
just as knowledge can be acquired from experts or from data sets of
correct solutions, knowledge can also be validated by experts or by
data sets of correct solutions.  Knowledge can also be validated
experimentally, by determining if the system as a whole works and has
the intended effect on its users.
Of course care must be taken that
the validation process uses different resources than the acquisition
process.  For example, knowledge acquired from an expert should not be validated
by that expert, and knowledge learned from a data set should not be
validated by that data set. 

There has not been a great deal of previous research on knowledge
acquisition for \nlg{}; \citeA{Reiter:nlg00} summarise previous
efforts in this area.  Generally corpus analysis (analysis of
collections of manually written texts) has been the most
popular \ka{} technique for \nlg{}, as in other areas of Natural
Language Processing, although sometimes it is supplemented by
expert-oriented techniques \cite{Goldberg:ieee94,Mckeown:anlp94}.
\citeA{Walker:csl02} have attempted to
learn \nlg{} rules from user ratings of generated texts, which can perhaps
be considered a type of experiment-based \ka{}.


\subsection{STOP}

\stopgen{} \fullcite{Reiter:aij03} is an \nlg{} system that
generates tailored smoking-cessation letters.  Tailoring
is based on a 4-page multiple-choice
questionnaire about the smoker's habits, health,
concerns, and so forth.  An extract from a questionnaire is shown in
Figure~\ref{quest-fig}, and an extract from the \stopgen{} letter
generated from this questionnaire is shown in
Figure~\ref{letter-fig} (we have changed the name of the smoker
to preserve confidentiality).
From a \ka{} perspective,
the most important knowledge needed in \stopgen{} is what content
and phrasing
is appropriate for an individual smoker; for example,
\begin{itemize}
\item What information should be given in a letter?  The example letter in
Figure~\ref{letter-fig}, for instance, emphasises things the smoker
dislikes about smoking, confidence building, and dealing with stress
and weight gain;
but it does not recommend specific techniques for stopping smoking.
\item Should a letter adopt a positive \scare{you'll feel better if
you stop} tone (as done in the letter in Figure~\ref{letter-fig}),
or should it adopt a negative \scare{smoking is
killing you} tone?
\end{itemize}
\stopgen{} was never operationally deployed, but it was tested with
real smokers in a clinical trial, during which 857 smokers received
\stopgen{} letters \cite{Lennox:bmj01}.
This evaluation, incidentally, showed that
\stopgen{} letters were no more effective than control non-tailored letters.

\restylefloat{figure}
\begin{figure}[H]
\begin{center}
\includegraphics[height=0.9\textheight]{quest1.eps}
\end{center}
\caption{First page of example smoker questionnaire}\label{quest-fig}
\end{figure}

\restylefloat{figure}
\begin{figure}[H]
\includegraphics[height=0.9\textwidth,angle=90]{tailor2.eps}
\caption{Extract from letter generated from Figure~\ref{quest-fig} questionnaire}\label{letter-fig}
\end{figure}

Knowledge acquisition in \stopgen{} was primarily based on
structured expert-oriented \ka{} techniques, including in particular
sorting and think-aloud protocols.
Knowledge was acquired from five health professionals;
three doctors, a nurse, and a health psychologist.
These experts were knowledgeable about smoking and about patient
information, but they were not experts on writing tailored
smoking-cessation letters.  In fact there are no experts at
this task, since no one manually writes tailored smoking-cessation letters.




It is not unusual for an \nlg{} system to attempt a task
which is not currently performed by human experts;
other examples include descriptions of software
models \cite{Lavoie:anlp97}, customised descriptions of museum
items \cite{Oberlander:hrhm98}, and written feedback for
adult literacy students \cite{Williams:enlg03}. Knowledge validation in \stopgen{} was mostly based on feedback from
users (smokers), and on the results of the clinical trial.

\subsection{SumTime-Mousam}

\begin{figure}[t]
\centering
\begin{tabular}{|rr|rrr|} \hline
day & hour & wind      & wind speed & wind speed\\ 
    &      & direction & (10m altitude) & (50m alt) \\ \hline
12-06-02 & 6 & WSW & 10 & 12\\
12-06-02 & 9 & WSW & 9 & 11\\
12-06-02 & 12 & WSW & 7 & 9\\
12-06-02 & 15 & WSW & 7 & 9\\
12-06-02 & 18 & SW & 7 & 9\\
12-06-02 & 21 & SSW & 8 & 10\\
13-06-02 & 0 & SSW & 10 & 12\\
 \hline
\end{tabular}
\caption{Wind data extract from 12-Jun-2002 numerical weather prediction}\label{wind1-table}
\end{figure}
%\restylefloat{figure}
\begin{figure}
\lineacross{}
FORECAST 6 - 24 GMT, Wed 12-Jun 2002\\
\begin{tabular}{rl}
\multicolumn{1}{l}{WIND(KTS)} \\
 10M: & WSW 8-13 gradually backing SW by early evening and SSW by\\
      & midnight. \\
 50M: & WSW 10-15 gradually backing SW by early evening and SSW by\\
      & midnight. \\
\multicolumn{1}{l}{WAVES(M)} \\
SIG HT: & 0.5-1.0 mainly SW swell.\\
MAX HT:	& 1.0-1.5 mainly SW swell. \\
\multicolumn{1}{c}{PER(SEC)} \\
 & WAVE PERIOD: Wind wave 3-5 mainly 6 second SW swell. \\
 & WINDWAVE PERIOD: 3-5. \\
 & SWELL PERIOD: 5-7.  \\
\multicolumn{1}{l}{WEATHER:} & Partly cloudy becoming overcast with light rain around midnight.\\
\multicolumn{1}{l}{VIS(NM):} & Greater than 10 reduced to 5-8 in precipitation.\\
\multicolumn{1}{l}{AIR TEMP(C):} & 8-10 rising 9-11 around midnight.\\
\multicolumn{2}{l}{CLOUD(OKTAS/FT): 2-4 CU/SC 1300-1800 lowering 7-8 ST/SC 700-900 around} \\
     & midnight.\\
\end{tabular}
\caption{Extract from forecast generated for 12-Jun-2002}\label{forecast1-fig}
\lineacross{}
\end{figure}

\sumtime{} \cite{Sripada:es02} is an \nlg{} system that generates
marine weather forecasts for offshore oil rigs,
from numerical weather simulation data.  An extract from
\sumtime{}'s input data is shown in Figure~\ref{wind1-table},
and an extract from the forecast generated from this data
is shown in Figure~\ref{forecast1-fig}.
From a \ka{} perspective,
the main knowledge needed by \sumtime{} was again what content
and expression was best for users; for example,
\begin{itemize}
\item What changes in a meteorological parameter
are significant enough to be reported in the text?  The forecast
in Figure~\ref{forecast1-fig}, for example, mentions
changes in wind direction but not changes in wind speed.
\item What words and phrases should be used to communicate time?
For example, should 1800 be described as \lingform{early evening}
(as in Figure~\ref{forecast1-fig})
or as \lingform{late afternoon}?
\end{itemize}
\sumtime{} is currently being used operationally by a meteorological
company, to generate draft forecasts which are post-edited by human
forecasters.

Knowledge acquisition in \sumtime{} was based on both corpus analysis
of manually-written forecasts and structured \ka{} with expert
meteorologists.  Unlike the experts we worked with in \stopgen{},
the meteorologists we worked with in \sumtime{}
were experienced at writing the target texts (weather forecasts).
The forecast corpus included the numerical weather simulation data
that the forecasters used when writing the forecasts,
as well as the actual forecast texts \cite{Sripada:corpus03}.

Knowledge validation in \sumtime{} has mostly been conducted by
checking knowledge acquired from the corpus with the experts, and checking
knowledge acquired from the experts against the corpus.  In other words,
we have tried to make the validation technique as different
as possible from the acquisition technique.
We are currently evaluating \sumtime{} as a system by measuring
the number of edits that forecasters make to the computer-generated
draft forecasts.



\section{Knowledge Acquisition Techniques Tried}
\begin{table}
\centering
\begin{tabular}{|l|l|l|l|l|} \hline
{\bf Techniques} & {\bf Advantages} & {\bf Disadvantages} & {\bf When} &
{\bf Types of } \\
   &  &  & {\bf Useful} & {\bf Knowledge} \\ \hline
directly ask & get big picture & many gaps, may & initial & domain, \\
experts      &             &  not match practice  & prototype & DCK \\ \hline
structured \ka{} & get details, & limited coverage,  & flesh out & depends \\
with experts & get rationale & experts variable & prototype & on expert \\ \hline
corpus & get lots of  & hard to create, & robustness, & DCK, \\ 
analysis       & knowledge & texts inconsistent, & unusual cases & communication\\
                & quickly          & poor models for \nlg{} &   & \\ \hline
expert     & fix problems & local optimisation, & improve & all\\
revision   & in knowledge & not major changes & system & \\ \hline
\end{tabular}
\caption{Summary Evaluation of \ka{} techniques for \nlg{}}\label{summary-table}
\end{table}

In this section we summarise the main \ka{} techniques we used in
\stopgen{} and \sumtime{}.  For each technique we give an example of
the knowledge acquired, and discuss what we learned
when we tried to validate the knowledge.
Table~\ref{summary-table} gives a very high level overview of the
major advantages and disadvantages of the different techniques
we tried, when the different techniques were perhaps most useful,
and what types of knowledge they were best suited to acquiring
(using the classification of Section~\ref{nlg-knowledge}).
As this table shows, no one technique is clearly best;
they all have different strengths and weaknesses.  Probably the best
overall \ka{} strategy is to use a mix of different techniques;
we will further discuss this in Section~\ref{our-methodology}.

\subsection{Directly Asking Experts for Knowledge}

The simplest and perhaps most obvious \ka{} technique for \nlg{}
is to simply ask experts how to write the texts in question.
In both \stopgen{} and \sumtime{},
experts initially gave us spreadsheets or flowcharts
describing how they thought texts should be generated.  In both projects,
it also turned out that the experts' description of how texts should be
generated did not in fact match how people actually wrote the texts
in question.  This is a common finding in \ka{}, and it is
partially due to the fact that it is difficult for experts to
introspectively examine the knowledge they use in practice
\cite{Anderson:book95}; this is why proponents of expert-oriented \ka{}
prefer structured \ka{} techniques.

For example, at the beginning of \sumtime{}, one of the meteorologists
gave us a spreadsheet which he had designed, which
essentially encoded how he thought some parts of weather forecasts should be
generated (the spreadsheet did not generate a complete weather forecast).
We analysed the logic used in the spreadsheet, and
largely based the first version of \sumtime{} on this logic.

One goal of our analysis was to create an algorithm that could
decide when a change in a
parameter value was significant enough so that it
should be mentioned in the weather report.
The spreadsheet used context-dependent change thresholds to make this
decision.  For example, a change in the wind speed would be mentioned if
\begin{itemize}
\item the change was 10 knots or more, and the final wind speed was
15 knots or less;
\item the change was 5 knots or more, and the final wind speed was
between 15 and 40 knots; or
\item the change was 10 knots or more, and the final wind speed was
over 40 knots.
\end{itemize}
The context-dependent thresholds reflect the usage of the weather
reports by the users (in this case, oil company staff making
decisions related to North Sea offshore oil rigs).
For example, if a user is deciding how to unload a supply boat,
moderate changes in wind speed don't matter at low speeds (because light
winds have minimal impact on supply boat operations)
and at high speeds (because the boat
won't even attempt to unload in very heavy winds), but may affect
decisions at in-between speeds.  The context-dependent thresholds
would be expected to vary according to the specific forecast recipient,
and should be set in consultation with the recipient.

From our perspective, there were two main pieces of knowledge encoded
in this algorithm:
\begin{enumerate}
\item The absolute size of a change determines whether it should be mentioned
or not, and
\item The threshold for significance depends on the context and
ultimately on how the user will use the information.
\end{enumerate}

\subsubsection{Validation of Direct Expert Knowledge}
We checked these rules by comparing them to what we
observed in our corpus analysis of manually written forecasts
(Section~\ref{corpus-analysis}).
This suggested that while (2)
above is probably correct, (1) may be incorrect.  In particular,
a linear segmentation model \cite{Sripada:es02},
which basically looks at changes in slope
rather than changes in the absolute value of a parameter, better matches
the corpus texts.
The expert who designed the spreadsheet model agreed that segmentation
was probably a better approach.
He also essentially commented that one
reason for his use of the absolute size model was that this was
something that was easily comprehensible to someone who was neither
a programmer nor an expert at numerical data analysis techniques.

In other words, in addition to problems in introspecting knowledge,
it also perhaps is not reasonable to expect a domain expert
to be able to write a sophisticated data analysis algorithm based
on his expertise.  This is not an issue if the knowledge needed is
purely declarative, as it is in many \ai{} applications; but if
we need procedural or algorithmic knowledge, we must bear in mind
that domain experts may not have sufficient
computational expertise to express their knowledge as a computer
algorithm.

\subsubsection{Role of Directly Asking Experts for Knowledge}

Although the expert's spreadsheet in \sumtime{} was far from ideal,
it was extremely useful as a starting point.  It specified an initial
system which we could build fairly easily, and which produced at least
vaguely plausible output.  Much the same in fact happened in \stopgen{},
when one of the doctors gave us a flowchart which certainly had many
weaknesses, but which was useful as an initial specification of
a relatively easy-to-build and somewhat plausible system.  In both
\stopgen{} and \sumtime{}, as indeed in other \nlg{} projects we have
been involved in, having an initial prototype system working as soon
as possible was very useful for developing our ideas and for explaining
to domain experts and other interested parties what we were trying to do.

In terms of the types of knowledge mentioned in Section~\ref{nlg-knowledge},
both the \stopgen{} flowchart and the \sumtime{} spreadsheet specified
domain knowledge (for example, how smokers should be categorised)
and domain communication knowledge (for example, the use of ranges instead
of single numbers to communicate wind speed).
The \stopgen{} flowchart did not specify
any generic communication knowledge such as English grammar and morphology;
the author probably believed we knew more about such things than he did.
The \sumtime{} spreadsheet did in effect include a few English grammar rules, but
these were just to get the spreadsheet to work, the author did not have
much confidence in them.

In summary, we think directly asking experts for knowledge is an
excellent way to quickly build an initial system, especially if the \nlg{}
developers can supply communication knowledge that the domain expert
may not possess.  But once the initial
system is in place, it is probably best to use other \ka{} techniques,
at least in poorly understood areas such as \nlg{}.  However,
in applications
where there is a solid theoretical basis, and the expert can simply say
\scare{build your system according to theory X}, an expert's direct
knowledge may perhaps be all that is needed.


\subsection{Structured Expert-Oriented KA: Think-Aloud Protocols}\label{structured-ka}

There are numerous types of structured expert-oriented \ka{} techniques,
including think-aloud protocols, sorting, and structured interviews
\cite{Scott:book91}.
We will focus here on think-aloud protocols, which is
the technique we have used the most.
We have tried other structured \ka{} techniques as well, such as
sorting \cite{Reiter:nlg00}; we will not describe these here, but
our broad conclusions about other structured \ka{} techniques were
similar to our conclusions about think-aloud protocols.

In a think-aloud protocol, an expert carries out the task in question
(in our case, writing a text) while \scare{thinking aloud} into
an audio (or video) recorder.
We used think-aloud protocols in both \stopgen{} and \sumtime{}.
They were especially important in \stopgen{}, where they provided
the basis for most content and phrasing rules.

A simple example of the think-aloud process is as follows.  One of the doctors
wrote a letter for a smoker who had tried to stop before, and managed
to stop for several weeks before starting again.  The doctor made the
following comments in the think-aloud transcript:

\begin{quote}
Has he tried to stop smoking before?  Yes, and the longest he has
managed to stop --- he has ticked the one week right up to three months
and that's encouraging in that he has managed to stop at least once
before, because it is always said that the people who have had one or two
goes are more likely to succeed in the future.
\end{quote}

He also included the following paragraph in the letter that he wrote
for this smoker:
\begin{quote}
I see that you managed to stop smoking on one or two occasions before
but have gone back to smoking, but you will be glad to know that this
is very common and most people who finally stop smoking have had one or
two attempts in the past before they finally succeed.  What it does
show is that you are capable of stopping even for a short period, and that
means you are much more likely to be able to stop permanently than
somebody who has never ever stopped smoking at all.
\end{quote}

After analysing this session, we proposed two rules:
\begin{itemize}
\item IF (previous attempt to stop) THEN (message: more likely to succeed)
\item IF (previous attempt to stop) THEN (message: most people who stop have
a few unsuccessful attempts first)
\end{itemize}

The final system incorporated a rule (based on several \ka{} sessions, not
just the above one) that stated that if the smoker had tried to stop
before, and if the letter included a section on confidence building,
then the confidence-building section
should include a short message about
previous attempts to stop.  If the smoker had managed to quit for more
than one week, this should be mentioned in the message; otherwise the
message should mention the recency of the smoker's previous cessation
attempt if this was within the past
6 months.  The actual text generated from this rule in the example
letter of Figure~\ref{letter-fig} is

{\samepage
\begin{quote}
Although you don't feel confident that you would be able to stop if you
were to try, you have several things in your favour.
\begin{itemize}
\item You have stopped before for more than a month.
\end{itemize}
\end{quote}
}

Note that the text produced by the actual \stopgen{} code
is considerably simpler than the text originally written by the expert.
This is fairly common, as are simplifications in the logic used to decide
whether to include a message in a letter or not.  In many cases
this is due to the expert having much more knowledge and
expertise than the computer
system \cite[pp 30--36]{Reiter:book00}.
In general, the process of deriving implementable rules for \nlg{}
systems from
think-aloud protocols is perhaps more of an art than a science,
not least because different experts often write texts in very
different ways.


\subsubsection{Validation of Structured KA Knowledge}\label{think-aloud-evaluation}

We attempted to verify some of the rules acquired from \stopgen{} think-aloud
sessions by performing a series of small experiments where we asked
smokers to comment on a letter, or to compare two versions of a letter.
Many of the rules were supported by these
experiments - for example, people in general liked the recap of
smoking likes and dislikes (see {\bf You have good reasons to stop\ldots}
section of Figure~\ref{letter-fig}).
However, one general negative finding of these
experiments was that the tailoring rules were insufficiently sensitive
to unusual or atypical aspects of individual smokers; and most smokers
were probably unusual or atypical in some way.
For example, \stopgen{} letters did
not go into the medical details of smoking (as none of the think-aloud
expert-written
letters contained such information), and while this
seemed like the right choice for many smokers, a few smokers did say that
they would have liked to see more medical information about smoking.
Another example is that (again based on the think-aloud sessions) we adopted
a positive tone and did not try to scare smokers; and again this seemed
right for most smokers, but some smokers said that a more \scare{brutal}
approach would be more effective for them.

The fact that our
experts did not tailor letters in such ways may possibly reflect the
fact that such tailoring would not have been appropriate for the
relatively small number of
specific cases they considered in our think-aloud sessions.
We had 30 think-aloud sessions with experts, who looked at
24 different smoker questionnaires
(6 questionnaires were considered by two experts).
This may sound like a lot, but it is a drop in the ocean
when we consider how tremendously variable people are.

Comments made by smokers during the \stopgen{} clinical trial
\fullcite{Reiter:aij03} also revealed some problems with think-aloud
derived rules.  For example, we decided not to include practical
\scare{how-to-stop} information in letters for
people not currently intending to stop smoking; smoker comments
suggest that this was a mistake.  In fact, some experts did include
such information in think-aloud letters for such people,
and some did not.
Our decision not to include this information was influenced by the
Stages of Change theoretical model \cite{Prochaska:book92}
of behaviour change, which states that
\scare{how-to-stop} advice is inappropriate for people not currently
intending to stop;
in retrospect, this decision was probably a mistake.

We repeated two of our think-aloud exercises
15 months after we originally performed them; that is, we went back
to one of our experts and gave him two questionnaires he had analysed
15 months earlier, and asked him to once again think aloud while
writing letters based on the questionnaires.
The letters that the expert wrote in the second session were somewhat
different from the ones he had originally written, and were preferred by
smokers over the letters he had originally written
\cite{Reiter:nlg00}.  This suggests that our experts were not static
knowledge sources, but were themselves learning about the
task of writing tailored smoking-cessation letters
during the course of the project.  Perhaps this should not be a surprise
given that none of the
experts had ever attempted to write such letters before
getting involved with our project.

\subsubsection{Role of Structured Expert-Oriented KA}\label{role-structured-ka}

Structured expert-oriented \ka{} was certainly a useful way to
expand, refine, and generally improve initial prototypes constructed
on the basis of experts' direct knowledge.  By focusing on actual cases
and by structuring the \ka{} process, we learned many things which
the experts did not mention directly.  We obtained all the types of
knowledge mentioned in Section~\ref{nlg-knowledge},
by working with experts with the relevant
expertise.  For example in \stopgen{} we acquired domain
knowledge (such as the medical effects of smoking) from doctors,
domain communication knowledge (such as which words to use)
from a psychologist
with expertise in writing patient information leaflets, and
communication knowledge about graphic design and layout from a
graphic designer.

However, structured expert-oriented \ka{} did have some problems,
including in particular coverage and variability.
As mentioned above, 30 sessions that examined 24 smoker questionnaires
could not possibly
give good coverage of the population of smokers, given how complex
and variable people are.
As for variation, the fact that different experts wrote
texts in very different ways made it difficult to
extract rules from the think-aloud protocols.  We undoubtably made
some mistakes in this regard, such as not giving
\scare{how-to-stop} information to people not currently
intending to stop smoking.
Perhaps we should have focused on a single
expert in order to reduce variation.  However, our experiences suggested that
different experts were better at different types of information,
and also that experts changed over time (so we might see substantial
variation even in texts from a single author);
these observations raise doubts
about the wisdom and usefulness of a single-expert strategy.

In short, the complexity of \nlg{} tasks means that a very large number
of structured \ka{} sessions may be needed to get good coverage; and
the fact that there are numerous ways to write texts to fulfill a
communicative goal means that different experts tend to write very
differently, which makes analysis of structured \ka{} sessions difficult.


\subsection{Corpus Analysis}\label{corpus-analysis}

In recent years there has been great interest in Natural Language
Processing and other areas of \ai{} in using machine
learning techniques to acquire knowledge from relevant data sets.
For example, instead of building a
medical diagnosis system by trying to understand how expert doctors diagnose
diseases, we can instead analyse data sets of observed symptoms
and actual diseases, and use statistical
and machine learning techniques to determine which symptoms
predict which disease.  Similarly, instead of building an English grammar
by working with expert linguists, we can instead analyse large collections
of grammatical English texts in order to learn the allowable structures
(grammar) of such texts.  Such collections of texts are called
{\em corpora} in Natural Language Processing.

There has been growing interest in applying such techniques to learn
the knowledge needed for \nlg{}.
For example, 
\citeA{Barzilay:acl01} used corpus-based machine learning to learn
paraphrase possibilities;
\citeA{Duboue:acl01} used corpus-based machine learning to learn how
NP constituents should be ordered;
and \citeA{Hardt:acl01} used corpus-based machine learning to learn
rules for VP ellipsis.

Some \nlg{} researchers, such as \citeA{Mckeown:anlp94}, have used the term
\scare{corpus analysis} to refer
to the manual analysis (without using machine learning techniques)
of a small set of texts which are written explicitly for the \nlg{} project
by domain experts (and hence are not naturally occurring).
This is certainly a valid and valuable
\ka{} technique, but we regard it as a form of structured expert-oriented
\ka{}, in some ways similar to think-aloud protocols.  In this paper,
\scare{corpus analysis} refers to the use of machine learning and statistical
techniques to analyse collections of naturally occurring texts.

Corpus analysis in our sense of the word
was not possible in \stopgen{} because we did not have
a collection of naturally occurring texts (since doctors do not currently
write personalised smoking-cessation letters).
We briefly considered analysing
the example letters produced in the think-aloud sessions with machine
learning techniques, but we only had 30 such texts, and we believed this
would be too few for successful learning,
especially given the high variability between experts.
In other words, perhaps the primary
strength of corpus analysis is its ability to extract information from
large data sets; but if there are no large data sets to extract information
from, then corpus analysis loses much of its value.

In \sumtime{}, we were able to acquire and analyse
a substantial corpus of 1099
human-written weather forecasts, along with the data files that
the forecasters
looked at when writing the forecasts \cite{Sripada:corpus03}.
Details of our corpus analysis procedures and
results have been presented elsewhere
\cite{Reiter:cl02,Sripada:corpus03}, and will not be repeated here.

\subsubsection{Validation of Corpus Analysis Knowledge}

\begin{table}[t]
\centering
\begin{tabular}{|r|rrrrrr|r|} \hline
form & F1 & F2 & F3 & F4 & F5 & unknown & total \\ \hline
\lingform{5}  & 0 & 7 & 0 & 0 & 122 & 4 & 133 \\
\lingform{05} & 0 & 0 & 1 & 46&   0 & 2 & 49 \\ \hline
\lingform{6}  & 0 & 44& 0 & 0 &  89 & 2 & 135 \\
\lingform{06} & 0 & 0 &364&154&   0 &13 & 531 \\ \hline
\end{tabular}
\caption{Usage of \lingform{5}, \lingform{05}, \lingform{6},
\lingform{06} in wind statements, by forecaster}\label{form-table}
\end{table}

While many of the rules we acquired from corpus analysis
were valid, some rules were problematical, primarily due to two factors:
individual variations between the writers, and writers making choices
that were appropriate for humans but not for \nlg{} systems.

A simple example of individual variation and the problems it
causes is as follows.
One of the first things we attempted to learn from the corpus was
how to express numbers in wind statements.  We initially did this
by searching for the most
common textual realisation of each number.  This resulted in rules that
said that 5 should be expressed as \lingform{5}, but 6 should be expressed
as \lingform{06}.  Now it is probably acceptable for a forecast to
always include leading zeros for single digits (that is, use \lingform{05}
and \lingform{06}), and to never include leading zeros (that is, use
\lingform{5} and \lingform{6}).
However, it is probably not acceptable to mix the two (that is, use
\lingform{5} and \lingform{06} in the same forecast),
which is what our rules would have led to.

The usage of \lingform{5}, \lingform{05}, \lingform{6}, and
\lingform{06} by each individual forecaster is shown in Table~\ref{form-table}.
As this table suggests, each individual forecaster is consistent;
forecasters F3 and F4 always include leading zeros, while forecasters
F2 and F5 never include leading zeros.  F1 in fact is also consistent
and always omits leading zeros;
for example he uses \lingform{8} instead of \lingform{08}.
The reason that the overall statistics favour \lingform{5} over
\lingform{05} but \lingform{06} over \lingform{6} is that
individuals also differ in which descriptions of wind speed
they prefer to use.  For example, F1 never explicitly mentions
low wind speeds such as 5 or 6 knots, and instead always uses
generic phrases such as \lingform{10 OR LESS}; F2, F4, and F5 use a mix
of generic phrases and explicit numbers for low wind speeds; and F3
always uses explicit numbers and never uses generic phrases.
Some of the forecasters
(especially F3) also have a strong preference for even numbers.
This means that the statistics for \lingform{5} vs.\ \lingform{05} are
dominated by F5 (the only forecaster who both explicitly mentions low
wind speeds and does not prefer even numbers); while the statistics for
\lingform{6} vs.\ \lingform{06} are dominated by F3 (who uses this number
a lot because he avoids both generic phrases and odd numbers).
Hence the somewhat odd result that the corpus
overall favours \lingform{5} over
\lingform{05} but \lingform{06} over \lingform{6}.

This example is by no means unique.  \citeA{Reiter:inlg02} explain
how a more complex analysis using this corpus, whose goal was to determine
the most common time phrase
for each time, similarly led to unacceptable rules, again largely because
of individual differences between the forecasters.

There are obvious methods to deal with the problems caused by
individual variation.
For example, we could restrict the corpus to texts from one author;
although this does have the major
drawback of significantly reducing the size of
the corpus.  We could also use a more sophisticated model, such as
learning one rule for how all single digit numbers are expressed,
not separate rules for each number.  Or we could analyse
the behaviour of individuals and identify choices (such as presence
of a leading zero) that vary between individuals but are consistently made
by any given individual; and then make such choices parameters which the
user of the \nlg{} system can specify.  This last option is probably
the best for \nlg{} systems \cite{Reiter:enlg03}, and is
the one used in \sumtime{} for the leading-zero choice.

Our main point is simply that we would have been in trouble
if we had just accepted our initial corpus-derived rules
(use \lingform{5} and \lingform{06}) without question.
As most corpus researchers are of course aware, the result of
corpus analysis depends on what is being learned (for example,
a rule on how to
realise 5, or a rule on how to realise all single-digit numbers) and on what
features are used in the learning (for example, just the number, or the
number and the author).  In more complex analyses, such as our analysis of
time-phrase choice rules \cite{Reiter:inlg02}, the result also depends on
the algorithms used for learning and alignment.
The dependence of corpus analysis on these choices means that the
results of a particular analysis are not guaranteed to be correct
and need to be validated (checked) just like the results of other \ka{}
techniques.
Also, what is often the best approach from an \nlg{} perspective,
namely identifying individual variations and letting the user choose which
variation he or she prefers, requires analysing differences between
individual writers.  To the best of our knowledge most published \nl{}
corpus analyses have not done this,
perhaps in part because many popular corpora
do not include author information.

The other recurring problem with corpus-derived rules was cases where
the writers produced sub-optimal texts that in particular were shorter
than they should have been, probably because such texts were quicker
to write.
For instance, we noticed that when a parameter changed in a more or
less steady fashion throughout a forecast period, the forecasters
often omitted a time phrase.
For example, if a S wind rose steadily in speed from 10 to 20 over the
course of a forecast period covering a calendar day,
the forecasters might write
S 8-12 RISING TO 18-22, instead of S 8-12 RISING TO 18-22 BY MIDNIGHT.
A statistical corpus analysis showed that the \scare{null}
time phrase was the most common one in such contexts, used in
33\% of cases.  The next most common time phrase, \lingform{later},
was only used in 14\% of cases.
Accordingly, we programmed our system to omit the time phrase in such
circumstances.  However, when we asked experts to comment on and
revise our generated forecasts (Section~\ref{revision-section}),
they told us that this behaviour was incorrect, and that forecasts
were more useful to end users if they included explicit time phrases
and did not rely on the readers remembering when forecast periods
ended.  In other words, in this example the forecasters were
doing the wrong thing, which of course meant that the
rule produced by corpus analysis was incorrect.

We don't know why the forecasters did this, but discussions with
the forecast managers about this and other mistakes (such as forecast
authors describing wind speed and direction as changing at the same
time, even when they actually were predicted to change at different times)
suggested that
one possible cause is the desire to write forecasts quickly.
In particular, numerical weather predictions are constantly being updated,
and customers want their forecasts to be based on the most up-to-date
prediction; this can limit the amount of time available to write
forecasts.

In fact it can be perfectly rational for human writers to \scare{cut
corners} because of time limitations.  If the forecasters
believe, for example, that quickly writing a forecast at the last minute
will let them use more up-to-date prediction data;
and that the benefits
of more up-to-date data outweighs the costs of abbreviated texts,
then they are making the right decision when they write shorter-than-optimal
texts.  An \nlg{} system, however, faces a very different set of
tradeoffs (for example, omitting a time
phrase is unlikely to speed up an \nlg{} system), which means that
it should not blindly imitate the choices made by human writers.

This problem is perhaps a more fundamental one than the individual
variation problem, because it can not be solved by appropriate choices
as to what is being learned, what features are considered, and so forth.
Corpus analysis, however it is performed, learns the choice rules used
by human authors.  If these rules are inappropriate for an \nlg{}
system, then the rules learned by corpus analysis will be inappropriate
ones as well, regardless of how the corpus analysis is carried out.

In very general terms, corpus analysis certainly has many strengths,
such as looking at what people do in practice, and collecting
large data sets which can be statistically analysed.  But pure corpus
analysis does perhaps suffer from the drawback that it gives no information
on why experts made the choices they made, which means that blindly
imitating a corpus can lead to inappropriate behaviour when the human
writers face a different set of constraints and tradeoffs than the
\nlg{} system.

\subsubsection{Role of Corpus Analysis}

Corpus analysis and machine learning are wonderful ways to acquire
knowledge if
\begin{enumerate}
\item there is a large data set (corpus) that covers unusual and
boundary cases as well as normal cases;
\item the members of the data set (corpus) are correct in that they
are what we would like the software system to produce; and
\item the members of the data set (corpus) are consistent (modulo some
noise), for example any given input generally leads to the same output.
\end{enumerate}
These conditions are probably satisfied when learning rules for
medical diagnosis or speech recognition.  However, they were
not satisfied in our projects.  None of the above conditions were
satisfied in \stopgen{}, and only the first was satisfied in
\sumtime{}.

Of course, there may be ways to alleviate some of these problems.
For example, we could try to acquire general communication knowledge
which is not domain dependent
(such as English grammar) from general corpora such as the British
National Corpus; we could argue that certain aspects of manually
written texts (such as lexical usage) are unlikely to be adversely
affected by time pressure and hence are probably correct; and we could
analyse the behaviour of individual authors in order to enhance
consistency (in other words, treat author as an input feature on a
par with the actual numerical or semantic input data).
There is scope for valuable
research here, which we hope will be considered by people interested
in corpus-based techniques in \nlg{}.

We primarily used corpus analysis in \sumtime{} to acquire domain
communication knowledge, such as how to linguistically express numbers
and times in weather forecasts,
when to elide information, and sublanguage
constraints on the
grammar of our weather forecasts.  Corpus analysis of course can also be
used to acquire generic communication knowledge such as English grammar,
but as mentioned above this is probably best done on a large general
corpus such as the British National Corpus.  We did not use corpus analysis
to acquire domain knowledge about meteorology.  Meteorological researchers
in fact do use machine learning techniques to learn about meteorology,
but they analyse numeric data sets of actual and predicted weather,
they do not analyse textual corpora.

In summary,
machine learning and corpus-based techniques are
extremely valuable if the above conditions are satisfied, and in particular
offer a cost-effective solution to the problem of acquiring
the large amount of knowledge needed in complex \nlg{} applications
(Section~\ref{role-structured-ka}).  Acquiring large amounts of
knowledge using expert-oriented \ka{} techniques is expensive
and time-consuming because it requires many sessions with experts;
in contrast, if a large corpus of consistent and correct texts can
be created, then large amounts of knowledge
can be extracted from it at low marginal cost.
But like all learning techniques, corpus analysis is very vulnerable
to the \scare{Garbage In, Garbage Out} principle; if the corpus is
small, incorrect, and/or inconsistent, then the results of corpus
analysis may not be correct.


\subsection{Expert Revision}\label{revision-section}

In both \stopgen{} and \sumtime{}, we made heavy use of expert revision.
That is, we showed generated texts to experts and asked them to
suggest changes that would improve them.  In a sense, expert revision
could be considered to be a type of structured expert-oriented \ka{},
but it seems to have somewhat different strengths and weaknesses than
the techniques mentioned in Section~\ref{structured-ka},
so we treat it separately.

As an example of expert revision, an early
version of the \stopgen{} system used the phrase
\lingform{there are lots of good reasons for stopping}.  One of the
experts commented during a revision session that the phrasing should be
changed to emphasise that the reasons listed (in this particular section
of the \stopgen{} letter) were ones the smoker himself had selected in
the questionnaire he filled out.  This eventually led to the revised wording
\lingform{It is encouraging that you have many good reasons for stopping},
which is in the first paragraph of the example letter in
Figure~\ref{letter-fig}.
An example of expert revision in \sumtime{} was mentioned in
Section~\ref{corpus-analysis}; when we showed experts generated texts
that omitted some end-of-period time phrases, they told us this was
incorrect, and we should include such time phrases.

In \stopgen{}, we also tried revision sessions with recipients (smokers).
This was less successful than we had hoped.  Part of the
problem was the smokers knew very little about \stopgen{} (unlike our
experts, who were all familiar with the project), and often made comments
which were not useful for improving the system, such as \lingform{I did
stop for 10 days til my daughter threw a wobbly and then I wanted a
cigarette and bought some}.
Also, most of our comments came from  well-educated and
articulate smokers, such as university students.
It was harder to get
feedback from less well-educated smokers, such as
single mothers living in council (public housing) estates.
Hence we were unsure
if the revision comments we obtained were generally applicable or not.

\subsubsection{Validation of Expert Revision Knowledge}

We did not validate expert revision knowledge as we did with the
other techniques.  Indeed, we initially
regarded expert revision as a validation technique, not a \ka{}
technique, although in retrospect it probably makes more sense to
think of it as a \ka{} technique.

On a qualitative level, though, expert revision has certainly resulted
in a lot of useful knowledge and ideas for changing texts, and
in particular proved a very useful way of
improving the handling of unusual and boundary cases.  For example,
we changed the way we described uneventful days in \sumtime{}
(when the weather
changed very little during a day) based on revision sessions.

The comment was made during \stopgen{} that revision was
best at suggesting specific localised changes to generated text, and
less useful in suggesting larger changes to the system.
One of the \stopgen{} experts suggested, after the system was built,
that he might have been
able to suggest larger changes if we had explained the system's reasoning
to him, instead of just giving him a letter to revise.  In other words,
just as we asked experts to \scare{think-aloud} as they wrote letters,
in order to understand their reasoning,
it could be useful in revision sessions if experts understood what
the computer system was \scare{thinking} as well as what it actually
produced.  \citeA[page 260]{Davis:book82} have similarly pointed out
that explanations can help experts debug and improve knowledge-based
systems.


\subsubsection{Role of Expert Revision}

We have certainly found expert revision to be an extremely useful
technique for improving \nlg{} systems; and furthermore it is useful
for improving all types of knowledge (domain, domain communication,
and communication).
But at the same time revision
does seem to largely be a local optimisation technique.  If an
\nlg{} system is already generating reasonable texts, then revision
is a good way of adjusting the system's knowledge and rules to
improve the quality of generated text.  But like all local optimisation
techniques, expert revision may tend to push systems towards
a \scare{local optimum}, and may be less well suited to finding radically
different solutions that give a better result.



\section{Discussion: Problems Revisited}

In section 1 we explained that writing tasks can be difficult to automate because these are complex, often novel, poorly understood, and allow multiple solutions. In this section we discuss each of these problems in more detail, based on our experiences with \stopgen{} and \sumtime{}.
\subsection{Complexity}

Because \nlg{} systems communicate with humans, they need knowledge
about people, language, and how people communicate; since all of these
are very complex, that means that in general \nlg{} systems need a lot
of complex knowledge.  This is one of the reasons why knowledge
acquisition for \nlg{} is so difficult.  If we recall the distinction
in Section~\ref{nlg-knowledge} between domain knowledge, domain communication
knowledge, and communication knowledge, it may be that communication
knowledge (such as grammar) is generic and hence can be acquired
once (perhaps by corpus-based techniques) and then used in many
applications.  And domain knowledge is similar to what is needed by
other \ai{} systems, so problems acquiring it are not unique to \nlg{}.
But domain communication
knowledge, such as the optimal tone of a smoking letter and how this
tone can be achieved, or when information in a weather forecast
can be elided, is application dependent (and hence cannot be acquired
generically) and is also knowledge about language
and communication (and hence is complex).  Hence \ka{} for \nlg{} may
always require acquiring complex knowledge.

In our experience, the best way to acquire complex knowledge robustly
is to get information on how a large number of individual cases are
handled.  This can be done by corpus analysis if a suitable corpus can
be created.  It can also sometimes be done by expert revision, if experts
have the time to look at a large number of generated texts; in this regard
it may be useful to tell them to only comment on major problems and to
ignore minor difficulties.  But however the knowledge is acquired, it will
require a substantial effort.

\subsection{Novelty}

Of course, many \ai{} systems need complex knowledge, so the above
comments are hardly unique to \nlg{}.  But one aspect of \nlg{} which
perhaps is more unusual is that many of the tasks \nlg{} systems are
expected to perform are novel tasks that are not currently done by
humans.  Most \ai{} \scare{expert systems} attempt to replicate the
performance of human experts in areas such as medical diagnosis and
credit approval.  Similarly, most language
technology systems attempt to replicate the performance of human
language users in tasks
such as speech recognition and information retrieval.  But many \nlg{}
applications are like \stopgen{}, and attempt a task that
no human performs.  Even in \sumtime{}, an argument could be made that
the task humans actually perform is writing weather forecasts under time
constraints, which is in fact different from the task performed by
\sumtime{}.

Novelty is a fundamental problem, because it means that knowledge
acquired from expert-oriented \ka{}
may not be reliable (since the experts are not
in fact experts at the actual \nlg{} task), and that a corpus of
manually-written texts probably does not exist.  This means that none of
the \ka{} techniques described above are likely to work.  Indeed,
acquiring novel knowledge is almost the definition of scientific
research, so perhaps the only way to acquire such knowledge is to conduct
scientific research in the domain.
Of course, only some knowledge will need to be acquired in this way,
even in a novel application it is likely that much of the knowledge
needed (such as grammar and morphology) is not novel.

On the other hand, novelty perhaps is also an opportunity for \nlg{}.
One of the drawbacks of conventional expert systems is that their
performance is often limited to that of human experts, in which case
users may prefer to consult actual experts instead of computer systems.
But if there are no experts at a task, an \nlg{} system may be used even
if its output is far from ideal.

\subsection{Poorly Understood Tasks}

A perhaps related problem is that there are no good theoretical models
for many of the choices that \nlg{} systems need to make.
For example, the ultimate goal of \stopgen{} is to change
people's behaviour, and a number of colleagues have suggested that we
base \stopgen{} on
argumentation theory, as \citeA{Grasso:ijhcs00} did for their dietary
advice system.
However, argumentation theory focuses on persuading people
to change their beliefs and desires,
whereas the goal of \stopgen{} was more to
encourage people to act on beliefs and desires they already had.
In other words,
\stopgen{}'s main goal was to encourage people who already wanted to stop
smoking to make a serious cessation attempt, not to convince people who
had no desire to quit that they should change their mind about the
desirability of smoking.
The most applicable theory
we could find was Stages of Change \cite{Prochaska:book92}, and indeed
we partially based \stopgen{} on this theory.  However, the results of our
evaluation suggested that some of the choices and rules that
we based on
Stages of Change were incorrect, as mentioned in
Section~\ref{think-aloud-evaluation}.

Similarly, one of the problems in \sumtime{} is generating texts
that will be interpreted correctly despite the fact that different
readers have different idiolects and in particular probably
interpret words in different ways \cite{Reiter:cl02,Roy:csl02}.
Theoretical guidance on how to do this would have been very useful,
but we were not able to find any such guidance.

The lack of good theoretical models means that \nlg{} developers cannot
use such models to \scare{fill in the cracks} between
knowledge acquired from experts or from data sets, as can be done
by \ai{} systems in better understood areas such as scheduling or
configuring machinery.
This in turn means that a lot of knowledge must be acquired.
In applications where there is a good theoretical basis, the goal of
\ka{} is perhaps to acquire a limited amount of
high-level information about search strategies,
taxonomies, the best way to represent knowledge, etc; once these have
been determined, the details can be filled in by theoretical models.
But in applications where details
cannot be filled in from theory and need to be acquired, much more
knowledge is needed.  Acquiring such knowledge with
structured expert-oriented \ka{} could be extremely expensive
and time consuming.
Corpus-based techniques are cheaper
if a large corpus is available; however, the lack of
a good theoretical understanding perhaps contributes to
the problem that we do not know which behaviour we observe in the
corpus is intended to help the reader (and hence should be copied
by an \nlg{} system)
and which behaviour is intended to help the writer (and hence perhaps
should not be copied).


\subsection{Expert Variation}

Perhaps in part because of the lack of good theories,
in both \stopgen{}
and \sumtime{} we observed considerable variation between experts.
In other words, different experts wrote quite different texts
from the same input data.  In \stopgen{} we also discovered that experts
changed how they wrote over time (Section~\ref{think-aloud-evaluation}).

Variability caused problems for both structured expert-oriented \ka{}
(because different experts told us different things) and for
corpus analysis (because variation among corpus authors made it harder
to extract a consistent set of rules with good coverage).
However,
variation seems to have been less of a problem with revision.
We suspect this is because experts vary less when they
are very confident about a particular decision; and in revision experts
tended to focus on things they were confident about, which was not
the case with the other \ka{} techniques.

In a sense variability may be especially
dangerous in corpus analysis, because there is no information in a corpus
about the degree of confidence authors have in individual decisions,
and also because developers may not even realise that there is
variability between authors,
especially if the corpus does not include author information.
In contrast, structured expert-oriented techniques such as think-aloud
do sometimes give information about experts' confidence,
and also variations between experts are usually obvious.

We experimented with various techniques for resolving differences
between experts/authors, such as group discussions and focusing on
the decisions made by one particular expert.  None of these were
really satisfactory.  Given our experiences with revision, perhaps
the best way to reduce variation is to develop \ka{} techniques that
very clearly distinguish between decisions experts are confident in
and decisions they have less confidence in.



\section{Development Methodology: Using Multiple KA Techniques}\label{our-methodology}

From a methodological perspective, the fact that different \ka{}
techniques have different strengths and  weaknesses
suggests that it makes sense to use a mixture of several different
\ka{} techniques.  For example, if both structured expert-oriented \ka{}
and corpus analysis are used, then the explanatory information from the
expert-oriented \ka{} can be used to help identify which decisions
are intended to help the reader and which are intended to help the writer,
thus helping overcome a problem with corpus analysis; and the broader
coverage of corpus analysis can show how unusual and boundary
cases should be handled,
thus overcoming a problem with expert-oriented \ka{}.

It also may make sense to use different techniques
at different points in the development process.  For example,
directly asking experts for knowledge could be stressed at the initial
stages of a project, and used to build a very simple initial prototype;
structured \ka{} with experts and corpus analysis could be stressed during
the middle phases of a project, when the prototype is fleshed out
and converted into something resembling a real system;
and revision could be used in the later stages of a project, when
the system is being refined and improved.

This strategy, which is
graphically shown in Figure~\ref{methodology-fig}, is basically the one
we followed in both \stopgen{} and \sumtime{}.  Note that it suggests
that knowledge acquisition is something that happens throughout the
development process.  In other words, we do not first acquire knowledge
and then build a system; knowledge acquisition is an ongoing process
which is closely coupled with the general software development effort.
Of course, this is hardly a novel observation, and there are many
development methodologies for knowledge-based systems
that stress iterative development and
continual \ka{} \cite{Adelman:book97}.

\begin{figure}[t]
\centering
\includegraphics{method.eps}
\caption{Our Methodology}\label{methodology-fig}
\end{figure}

In the short term, we believe that using a development methodology
that combines different \ka{} techniques in this manner, and also
validating knowledge as much as possible, are the best
strategies for acquiring \nlg{} knowledge.  We also believe that
whenever possible knowledge that is acquired in one way should be
validated in another way.  In other words, we do not recommend
validating corpus-acquired knowledge using corpus techniques (even
if the validation is done with a held-out test set); or validating
expert-acquired knowledge using expert-based validation (even if
the validation is done using a different expert).  It is preferable
(although not always possible) to validate corpus-acquired knowledge
with experts, and to validate expert-acquired knowledge with a corpus.

Another issue related to development methodology
is the relationship between knowledge
acquisition and system evaluation.  Although these are usually considered
to be separate activities, in fact they can be closely related.
For example, we are currently running an evaluation
of \sumtime{} which is based on the number of edits that forecasters
manually make to computer-generated forecasts before publishing them; this is
similar to edit-cost evaluations of machine translation systems
\cite[page 823]{Jurafsky:book00}.  However, these edits are also an
excellent source of data for improving the system via expert revision.
To take one recent example, a forecaster edited the computer-generated
text \lingform{SSE 23-28 GRADUALLY BACKING SE 20-25} by dropping the
last speed range, giving
\lingform{SSE 23-28 GRADUALLY BACKING SE}.  This can be considered as
evaluation data (2 token edits needed to make text acceptable),
or as \ka{} data (we need to adjust our rules for eliding similar but not
identical speed ranges).

In other words, real-world feedback on the effectiveness and quality
of generated texts can often be used to either improve or evaluate
an \nlg{} system.  How such data should be used depends on the goals of
the project.
In scientific projects whose goal is to test hypotheses,
it may be appropriate at some point to stop improving a system and use all
new effectiveness data purely for evaluation and hypothesis testing;
in a sense this is analogous to holding back part of a corpus for testing
purposes.  In applied projects whose goal is to build a maximally useful
system, however, it may be more appropriate to use all of the effectiveness
data to improve the quality of the generated texts.


\section{Conclusion}

Acquiring correct knowledge for \nlg{} is very difficult, because
the knowledge needed is largely knowledge about people, language, and
communication, and such knowledge is complex and poorly understood.
Furthermore, perhaps because writing is more of an art than a science,
different people write very differently, which further complicates
the knowledge acquisition process; and many \nlg{} systems attempt
novel tasks not currently done manually, which makes it very hard to
find knowledgeable experts or good quality corpora.  Perhaps because
of these problems, every single \ka{} technique we tried in
\stopgen{} and \sumtime{} had major problems and limitations.

There is no easy solution to these problems.  In the short term,
we believe it is useful to use a mixture of different \ka{} techniques
(since techniques have different strengths and weaknesses), and to
validate knowledge whenever possible, preferably using a different
technique than the one used to acquire the knowledge.  It also helps
if developers understand the weaknesses of different techniques, such as
the fact that structured expert-oriented \ka{} may not give good coverage
of the complexities of people and language, and the fact that
corpus-based \ka{}
does not distinguish between behaviour intended to help the reader
and behaviour intended to help the writer.

In the longer term, we need more research on better \ka{} techniques
for \nlg{}.  If we cannot reliably acquire the knowledge needed by
\ai{} approaches to text generation, then there is no point in using
such approaches, regardless of how clever our algorithms or models are.
The first step towards developing better \ka{} techniques is to
acknowledge that current \ka{} techniques are not working well, and
understand why this is the case; we hope that this paper constitutes
a useful step in this direction.

\section*{Acknowledgements}
Numerous people have given us valuable comments over the past five years
as we struggled with \ka{} for \nlg{}, too many to acknowledge here.
But we would like to thank Sandra Williams for reading several drafts of
this paper and considering it in the light of her own experiences,
and to thank the anonymous reviewers for their very helpful comments.
We would also like to thank the experts we worked with in
\stopgen{} and \sumtime{}, without whom this work would not be possible.
This work was supported by
the UK Engineering and Physical Sciences Research Council (EPSRC),
under grants GR/L48812 and GR/M76881, and by the
Scottish Office Department
of Health under grant K/OPR/2/2/D318.






\bibliography{reiter}
\bibliographystyle{theapa}

\end{document}






