I have been reading about Dialog Flow and there is one thing that is still unclear for me. I'll try to give an example.
I want to implement a conversion as following:
User: Hello Google, what are some interesting cities?
Bot: Hello there! Sydney, New York and Berlin are nice.
User: Could you tell more about the second city?
Bot: Sure. New York is amazing. In New York, you can ...
As you see, I am building a data context. After the first question, we should remember that we answered Sydney, New York and Berlin, so we understand what the second city actually means in the second question.
Should we store this data in the webhook service or is this stored in a context in Dialog Flow? If we have to store such data in the webhook service, how can we distinguish between different ongoing conversations?
Storing it in a Dialogflow Context is an ideal solution - this is exactly what Contexts were made for! You phrased your question using the same term, and this is no coincidence.
Conceptually, you might do this with a setup like this:
User: What are some interesting cities?
Dialogflow sees no contexts and matches an Intent asking for cities.
Agent replies: Sydney, New York, and Berlin are nice.
Agent sets context "cities" with parameter "cities" -> "Sydney, New York, Berlin"
User: Tell me more about the second one?
Dialogflow has an Intent that expects an incoming context of "cities" with a text pattern like "Tell me more about the (number index) one?" It sends the request to that Intent along with the currently active contexts.
Agent get a parameter with the index and the context "cities". It looks up the parameter for it, turns the string into an array, and gets the city based on the index.
Agent replies: New York is a fun place to visit!
Agent sets context "city" with parameter "current" -> "New York"
User: Tell me more!
Dialogflow matches this phrase and that the "city" context is still active and sends it to an event that reports more.
Agent says: More awesome stuff about New York.
User: Tell me about that first city instead.
Dialogflow matches it against the same intent as before.
Agent says: Sydney is pretty cool.
Agent changes the "city" context so the parameter "current" -> "Sydney" and "previous" -> "New York".
You can now create other intents that handle phrases like "Compare these two" or "tell me more about the other one".
Update
This setup strikes a good balance between what Dialogflow does well (parse messages and determine the current state of the conversation) and what your webhook does well (determine the best answers to those questions).
You could probably do much of that inside Dialogflow, but it would start to get very very messy very quickly. You would need to create multiple Intents to handle the results from each value individually, which doesn't scale. You'd also need to create a Context for each city (so you'd have a "city_ny" and "city_sydney" Context), since you can only match on the presence of a Context, not the parameters it might have.
Using the webhook (even the built-in fulfillment system that we now have) will likely work much better.
Related
I have an entity (items) and its values are ('name', 'colour', 'awards')
I have three intents
Intent1 = Welcome Intent (user will get the options in the form of chips)
Intent2 = Select Option (bot will ask question to enter detail for selected option)
Intent3 = Update Option (bot will save the record and ask next option to update.)
Example -
bot: welcome! what you want to update? name, colour, awards.
user: name
bot: Enter your name.
user: John
bot: record updated, what to update next? name, colour, awards.
now the issue is awards have multiple fields to update, to update awards a user has to provide three things (award name, award date, award description)
What I want is when a user selects awards options from the chips then it should be taken to new intent where I will get all the data through slot filling.
The first thing to remember is that an Intent represents what the user has said and not what you are doing with what they have said. So it doesn't make sense to say that you are "going to an Intent".
Second, while slot filling seems like a good idea, it usually leads to further problems, since it doesn't handle conditional information well, or handle users if they skip around in what they want to update.
All of these are better solved by setting up a state machine where they are in the conversation, what information you need, and what they have provided so far. Based on these settings, you can prompt them yourself for what you expect next. (You may also find using one or several Dialogflow contexts useful for shaping how to accept results as well.)
So, for example, when the user has indicated they are updating the awards, it might work like this:
User: Awards
[Your fulfillment sets the 'awards' context with a parameter that we are prompting for the name.]
Bot: Ok, I'm going to need the award name, description, and when it was awarded. What is the name?
User: Merit
[This matches the Fallback Intent with an Input Context for 'awards', since it is free-form input. Your fulfillment stores this and sets the 'awards' context with a parameter that we are now prompting for the date.]
Bot: Got it, the award is named Merit. When was it awarded?
User: Today
[This matches an Intent with a training phrase of "<#sys.date>" and the Input Context of 'awards'. There are also training phrases for things like "It was awarded <#sys.date>" and so forth. Your fulfillment sets the date and sets the 'awards' context with a parameter that we're now prompting for description.]
Bot: Got it. Awarded on March 1st. What is the description?
User: They were awesome.
[This matches the Fallback Intent with the Input Context of 'awards' again, because it is still free-form input. Our fulfillment, however, knows that this is about the description this time, so it stores it and removes the 'awards' context since we've captured everything.]
Bot: I've recorded that as a description of "they were awesome" - sure thing. That was everything we needed for now. Do you want to update the name, colour, or awards next?
That all seems pretty straightforward. But consider if the conversation had gone this way:
User: Awards
[Your fulfillment sets the 'awards' context with a parameter that we are prompting for the name.]
Bot: Ok, I'm going to need the award name, description, and when it was awarded. What is the name?
User: [Having done this many times] They were given the award for Honor yesterday
[This might match an Intent with an Input Context of 'awards' and the training phrase of "Given the award for <#sys.any> <#sys.date>" and possibly "<#sys.date> they got an award for <#sys.any>". Your fulfillment sets the name and date from this, sees what information it still needs, and prompts with...]
Bot: Got it. Award named Honor. Awarded March 1. What is the description?
User: Actually, it is named Honorable Service
[This matches an Intent with a training phrase of "named <#sys.any>" and an Input Context for 'awards'. Your fulfillment changes the name stored, checks what we still need, and again prompts...]
Bot: Ok, I've changed the award name to Honorable Service. What is the description?
The first scenario could be handled by slot filling and simple prompting, but the second can't. Being able to handle more natural responses from people and more flexible prompting will be better for your users.
I have been working lately with Dialogflow to make chatbots to do some simple tasks. For instance with webhooks and youtube api where the user ask to show him a video and then the bot just answers with the youtube video url.
E.G.
USER SAYS
Show me Neil young harvest moon
AGENT SAYS
Here you go : https://www.youtube.com/watch?v=n2MtEsrcTTs
I do this by using a custom Entity I called "YoutubeQuery" I checked "Allow Automated expansion" and unchecked "Define Synonyms" then I just added 2 values "Kavinsky Night Call" and "Indigo Night Tamino"
In my Intent I just made a couple of training phrases like these:
And everything works.
Now my issue is with a new Agent which I called Orders
I want just to get Order Id's from the firestore database, but before getting there I'm running in kind of a huge problem
I defined the order's ID entity just like the one with the youtubeQuery. And I added some example Order ID's , I want them all to Start with OD and have 4digits after example (DX0001,DX0009,DX9999)
Afterwards I made the intent
Now unless I give the EXACT order ID's from the traininphrase or the ID examples I defined in the Entity it will always give me a response with an empty parameter OrderID
I start my intent by saying "my order" then I get prompted with "What is your ID?
So when I give an ID that has not been used in the training phrases of the Intent I get an empty value in the parameters like this:
But when I give an ID that has been used in the training phrases like for instance the first one DX0808 it does work...
How can I make this work without adding all the possible order id's ranging from DX0001 to DX9999 in the training phrases or the entity.
I mean it does work for my youtube query, I can put anything there it does "catch" the value. Any help please?
It looks like the required parameter is the problem here, my suggestion would be to:
Create intent to get the order id in one sentence without reprompt (turn off required on the order id) and id is always present, ex: "my id is DX0402". Include training response where only ID is provided like "DL3932", ex. below:
Set other intent for scenario when customer wants to provide the id but it is missing, for ex. customer says: "my id" and make your bot ask for the id as an response ex. "ok, provide me your id"
If you do it, in case user doesn't provide the id, intent 2 will be triggered and after id is provided you'll trigger intent 1.
Hope this makes sense.
I am writing you to ask a question about Dialogflow fulfillments.
I am trying to create an agent for Google Home and my backend is basically a web hook implemented in TypeScript.
In the conversation that I designed, the user requests to the agent to perform an action, providing a category as paramter. Now, the set of possible categories can vary through time, so I am using the entity type #sys.any to detect the parameter.
My problem is that, when on the fulfillment I try to identify the specific category on which the agent needs to take action, it may be the case that the requested paramter matches multiple cateogries, so I'd need a followup intent to ask the user to clarify which is the actual category it wants to select.
E.g. the conversation could be the following:
Agent: 'Welcome.'
User: 'Do action on **category**'
Agent: 'I have found **categoryA**, **categoryB** and **categoryC**. Please specify which one you want to select.'
User: 'Select the second || Select **categoryB**'
Agent: 'Great, action performed on **categoryB**'
Now, I was able to build this conversation using followup events and contexts: for example I created two followup events, one that detects the numbers and another that detects the text, so the user is driven on one or another depending on what it says (if the user says 'The first', a number is detected and in the backend I cycle the categories selecting the one that is associated to that index. I do a similar operation if the user says "categoryX", but inside a different intent).
What I want to understand is: what is the proper way to achieve that kind of conversation through the Node.js fulfillment API?
Thank you for any help.
From your description - you've done precisely the right thing (although you don't need followup intents).
When you reply with the options the user has, you include a Context that may contain the array of possible results. You then create Intents that have this as an Input Context, match either the index of the array (lets call this the match.index Intent) or by name (the match.name Intent).
In your webhook, the match.index Intent would determine which category was actually chosen, and then call a function that takes care of that category. Similarly, the webhook for match.name would take the parameter with the name and call the same function to take care of that category.
I've something that I don't succeed to understand.
Here the situation I would like to do :
Bot: Hello, what do you want to do ?
User: Search a product
Bot: Which
product are you looking for ?
User: Apple
Bot -> list of products
matched with apple
here is a fragment code :
function searchProduct() {
agent.add('Which product are you looking for ?');
// receive the product answer
//-> then research the matched product in DB
}
const intentMap = new Map();
intentMap.set('I want a product', searchProduct);
agent.handleRequest(intentMap);
In this code, I ask to user the product that he's looking for.
But when he answered "Apple", how can I receive the user response in the same function to continue my process ?
I know there is the "context" concept, but to continue the "search product" process, I need to come back in the function.
For now, I use dialog-fulfillment. And I try to understand this documentation to find the solution :
https://github.com/dialogflow/dialogflow-fulfillment-nodejs/blob/master/docs/WebhookClient.md
The short answer is that you can't (or, at the very least, shouldn't) do it in the "same" function. Each function represents an Intent, or what the user has communicated to us. In the function we need to do the following:
Determine what the user has said that is important to us.
Compute anything based on what they've said.
Send a reply to the user based on (1) and (2).
Once we have sent the reply to the user - that round of the conversation is over. We need to wait for the next Intent to be triggered by the user so we can repeat the above.
Contexts are used so we know which stage of the overall conversation we're in. As part of our reply (step 3 above), we can set a Context which will help Dialogflow determine which Intent should be triggered (and thus which function should be called to process what we know so far). Contexts can also store information about previous turns of the conversation.
Keep in mind that Intents aren't about what we say, but are about what the user says. The reply we send is based on what we need, and then we would use a single Intent to capture each part. The function that handles that Intent would store the answer in the Context and determine the next part of the question.
I have a conversation with dialogflow to select a favourite type of drink and then depending on the category of drink there are follow up questions (ie follow up intents).
Under the intent tab I have the following intents:
Default Welcome Intent
Favourite drink Intent
Coffee Intent
follow up
Soft Drink Intent
follow up
Juice Intent
follow up
I use the training phrase in the Favourite Drink Intent and ask:
"What is your favourite drink?"
And store the response in an entity #drink.
But I don't know how then to trigger the intent "soft drink", "juice" or "coffee" intents depending on the users response. If I was writing code I'd use a switch statement or if/else but that prob doesn't apply here.
I wasn't sure if I had to use the fulfillment inline editor or I could just do that from within the Intent UI.
Thanks
In general - think of Intents as capturing what the user could be saying. Although Intents also have replies, this isn't their primary purpose.
Depending what, exactly, you're trying to do, there are a few approaches. All three of them require fulfillment code, which you can do using the built-in editor, or (better) use a webhook more under your control
If you want to use Intents to determine how to reply
This isn't really the best idea, but it is possible. In your fulfillment code, you would have a switch statement against the parameter with the user's selection. Based on this, you would trigger a followup event from your fulfillment. Your other Intents would have the Event section populated with the possible events, and the system would pick which one to trigger and use for fulfillment/response.
This is a bit of a kludge for what you want, probably.
Update to clarify based on questions in the comments. Sending an event directly triggers a different Intent. Sometimes this is what you want, but it is somewhat exceptional. Most of the time you want to use one of the methods below. In particular, you should remember that Intents are mostly meant to represent what the user is trying to do (what they "intend" to do), and this is mostly represented by what they're saying. Intents are good to capture the complex ways people talk instead of forcing them into a phone-tree-like "conversation".
If you just want to reply to each possible user response differently
You can use the fulfillment webhook code to determine what response should be sent to the user. You don't indicate what library you're using, but in general you'd write code that would determine what message should be sent to the user based on the drink type selected and include that as the speech and/or display text in the response.
You wouldn't use the other, drink specific, Intents in these cases. There isn't any need for them. Unless...
You want to reply to each user response differently, and the followup conversation might be different
Remember - Intents are really best for specifying what you expect the user to say. Not what you expect to reply with. So it is reasonable that you may have a different conversation based on if they selected Coffee (where you might ask how much sugar they want) or Juice (where you might ask if they want a straw).
In this case, you would still do as you have in the previous case (use your fulfillment to include a tailored message in your reply, possibly to prompt them for that info) and include in the reply an Output Context indicating what their choice was. You should do this as part of the response, rather than setting it in the Intent, since you'll want to name it differently for each beverage type.
Then you can create Intents specific to each beverage type with what you expect the user today. For those specific to Coffee, you would set the Input Context to require that the coffee context has been set. The soda context if they specified soda, and so forth.
Update, since you indicated in your comment that this sounded like the avenue you were interested in.
In this scenario, you'd do as you described (almost):
Get the value for the drink parameter with code something like
const drink = request.body.queryResult.parameters.drink;
Do a switch based on this, and in the body of each case set what we'll reply with and what context we should remember. Something like this pseudocode, perhaps:
switch( drink ){
case 'coffee':
context = 'order_coffee';
msg = 'Do you want sugar with that?';
break;
case 'soda':
context = 'order_soda';
msg = 'Do you want a bottle or can?';
break;
case 'juice':
context = 'order_juice';
msg = 'Would you like a straw?';
break;
}
// Format JSON setting the message and context
You would then have Intents that would be triggered based on a combination of two things:
What the context is
What the user has said
For example, you would want a context (let's call it "coffee.black") which would be triggered if the order_coffee context is active and the user answered your question with "No" or "Just black" or other valid combinations.
But you'd want a different context (say, "juice.nostraw") if the order_juice context is active and the user replied "No".
And it wouldn't make much sense at all if the user said "No" while the order_soda context was active, so you'd want to try and direct them back to the subject at hand.
Remember, the Intent is for what the user says. Not for what your voice agent is saying. Your agent doesn't normally "trigger" an Intent - the user triggers it based on what they say.
In the example I gave, there might be other Intents that are valid for each of those contexts. For example, you might have a "coffee.sugar" Intent that is valid for the order_coffee context and responds to them saying "Yes". And another one where they might say "Just cream". There are lots of other things they might say as well, but it is important to your agent that the directions they're giving you have to do with ordering coffee.
As for your original question...
(To answer your original, now edited, question: Yes, you can create Intents from within your fulfillment. You almost certainly don't want to do this, however.)