[RavenclawDev 226] Re: swapping grammars for the ASR

[Dan Bohus]

Hi Svetlana, 

Thanks Antoine for the detailed response. Just wanted to add a short bit
to this... I think the idea of dynamically generating the grammar from
the expectation agenda is a really interesting research issue, and we've
kept saying for a while that someone should try that :) People generally
use state-specific language models or grammars, but generating it from
the expectation agenda is potentially more interesting, because it (can)
provide more fine-grained and dynamic control... for instance if you get
in the same dialog state through different paths in the dialog plan, the
expectation agenda might in fact look different. I think it's an
interesting path to explore. You could of course consider weighting
things based on how deep they are in the agenda (something near the top
is probably more likely that something near the bottom), and of course
you could think of all sorts of learning setups there, etc. 

In any case, if you go down that path, I'd be really curious to see what
happens. Keep us posted. 

Cheers,
Dan. 

-----Original Message-----
From: ravenclaw-developers-bounces at LOGANBERRY.srv.cs.cmu.edu
[mailto:ravenclaw-developers-bounces at LOGANBERRY.srv.cs.cmu.edu] On
Behalf Of Antoine Raux
Sent: Thursday, February 22, 2007 8:22 AM
To: ravenclaw-developers at cs.cmu.edu
Subject: [RavenclawDev 225] Re: swapping grammars for the ASR

Hi Svetlana,

Note that we are already using state-specific (statistical) LMs in our
current systems. The way we switch between LMs is through the
INPUT_LINE_CONFIGURATION directive which is generally used in REQUEST
agents
and agencies, as in the following example from Let's Go:

INPUT_LINE_CONFIGURATION( "set_lm=time, set_dtmf_len=1")

The specific syntax of the configuration string is dependent on
AudioServer
(RavenClaw just sends the slot-value pairs to AudioServer). Right now,
you
use set_lm to specify the LM name for the Sphinx 2/3 recognizers, and
set_dtmf_len to specify how many digits your DTMF recognizer should
expect.
Of course, you could add new directives, as long as you modify
AudioServer
so that it does the right thing (which is most likely sending the
directives
to each individual recognition engine).

So the current way to implement what you're proposing is to add an
INPUT_LINE_CONFIGURATION directive to all request agents that indicates
all
the rules that should be active at that time. 
Now, it might be interesting to have a default behavior that does what
you're saying (i.e. automatically building the LM configuration from the
expectation agenda). This could be achieved by overloading the
CDialogAgent
virtual method GetInputLineConfiguration, so it (optionally) constructs
a
list of active rules when called (it's already written so that it
inherits
unspecified slots from its parent agent, in addition to parsing the
string
specified in its own INPUT_LINE_CONFIGURATION). Another option is to
have RC
actually send the whole expectation agenda to AudioServer (it's already
sending it to Helios), but then you have to modify AudioServer to allow
it
to parse the full agenda.

Hope this helps...

antoine



-----Original Message-----
From: ravenclaw-developers-bounces at LOGANBERRY.srv.cs.cmu.edu
[mailto:ravenclaw-developers-bounces at LOGANBERRY.srv.cs.cmu.edu] On
Behalf Of
Svetlana Stenchikova
Sent: Wednesday, February 21, 2007 10:38 PM
To: ravenclaw-developers at cs.cmu.edu
Subject: [RavenclawDev 224] swapping grammars for the ASR

Hi,  we are using JSGF grammars with sphinx 4 recognizer.
The grammar of sphinx 4 is generated by converting the grammar of the
phoenix parser.
We would like  to be able to swap Sphinx 4 grammars during the
runtime. This functionality is supported by sphinx 4.


One of the solutions that we consider is to modify the dialog system
specific part of the DM:  create execute agents that call
enable/disable grammars on the ASR and place these agents manually in
the dialog tree. This is not a good solution because there will be a
duplication between what is passed to ASR and what is set in the
GRAMMAR_MAPPING directive on the dialog manager.

Another idea is to use the implementation of the GRAMMAR_MAPPING
directive  to make a call to the ASR component notifying it to change
the grammar.
>From looking at the code  CMAExpect::DeclareExpectations and
CMARequest::DeclareExpectations, each agent has a list of expected
grammatical rules.

So, when an agent is activated(or executed) it could potentially make
a call to the ASR component to notify it of the grammar in the current
state of the DM and to enable the rules that should be active at this
point of the dialog.
This would ensure the synchrony between the DM grammar and the ASR
grammar. This requires a 1-to-1 mapping between phoenix and ASR
grammars, which we comply with because ASR grammar is a conversion
from phoenix grammar.

Can you please tell us what do you think of this idea?
This functionality is currently not present in ravenclaw, right?
How difficult would it be to implement this?
Could you please give any pointers or suggestions for the
implementation?


Thank you

Svetlana