fmorbini / jmNL

modular NL platform for dialogue agents
Other
16 stars 2 forks source link

Out of scope utterance #5

Open jpbgameiro opened 6 years ago

jpbgameiro commented 6 years ago

Hi, I have a question about defining networks on the policy.txt, Unfortunately, I can't seem to understand from the online document if and how I could do this. Using the CakeVender as an example, we have the following network: Network flavorSponge {

topic: set.flavor

#entrance condition: system initiative
#condition: and(state=='start',type=='sponge',known(sugar))

#reentrance option: statement.back

system: question.cake.flavor
{
    {
        user: statement.flavor.chocolate
        #action: flavor='chocolate'
    }
    OR
    {
        user: statement.flavor.amaretto
        #action: flavor='amaretto'
    }
    OR
    {
        user: statement.flavor.lemon
        system: apology.flavor
        #action: clarifyFlavors=true
        #action: swapout
    }
}
DO
#action: state='done'
#goal: simple

} Here we have 3 possible user responses (chocolate, amaretto or lemon). But what if the user asks "What flavors do you have?" than it would not land on any of these options and the dialog just stops and I get no response from the bot. Is there any way to get the dialog manager to detect this other utterance and go to that network and then return here? Could you please give me a hint or a simple example on how I can accomplish this? Thanks! -João

fmorbini commented 6 years ago

consider a network like a function. construct your dialog as a series of reusable subdialogs. Each subdialog will be implemented as a network in the dialog policy. Each network can be initiated in two ways, with a user event, or information state condition. If you want to answer that question, then you need a network that deals with it (i.e. is initiated by that event) and also you either have to make the flavor network re-enterable (see reentrance condition) or initiatable by a system condition based on the information state.

hope this helps.

jpbgameiro commented 6 years ago

Hi Fabrizio, yes, that helped, but it seems to me that it becomes a bit hard to manage all the variables in the information state when I want it to be able to change to another branch in the conversation and only after that second branch is finished return to the first. If I do not have the reentry option it ignores my intent to change to another dialog branch and remains on the same network. O the other hand, if I add the reentry option it does execute the actions of the detected network but it always comes back to the same network because of the higher reward. So I'm guessing my only remaining option is to remove the "user:" (where he await for a response) and add a variable to the information state to know the question was just asked and then create a new Network where he waits for a specific user utterance when the question was already asked. Is that right?

Another thing I noticed (or am using wrongly) is that the timer condition for the CakeVender is not working. I tried adding conditions based on "timeSinceLastAction" to wait about 20 seconds and if nothing happened then say something, but it didn't do what I was expecting. For example, on the "Network wakeup {" I changed the condition to something like timeSinceLastAction>2234 and it takes the same time as if I deleted this condition.

fmorbini commented 6 years ago

Hi, we routinely use branching in our policies.

you should not have to comprise the design of your policy (but i also don't have bandwidth for look in detail and offer advice on your specific needs).

each subdialog should include the user actions that go with it, my advise is to not remove them from the branch they belong to.

reentrance options must be used only if you have a local state you want to remember (e.g. local variables of a network, and/or local position within the network).

rewards can be used anywhere, usually prompts have 0 reward, but if the branch is not a prompt (i.e. gathers information for the main network (the one that it interrupted)) then giving the branch a reward is perfectly fine.

i'm not aware of any issue with timing also, it was a feature routinely used.

feel free to fork and modify/debug the code as you see fit.