I have a custom Entity which is configured as allowing synonyms but without "fuzzy matching" and "allow auto expansion". This entity exists in an intent with a lot of training phrases.
For this problem, let's say I have an entity named Fruit with the values apple and pear as well as a training phrase that is "I would like to buy a $fruit".
If I invoke this intent with a phrase that exists as a training phrase I get my entity value resolved nicely.
But if I'd invoke the intent with an utterance, that includes an entity value, but doesn't exist as a training phrase the entity value is resolved to the entire utterance, which of course isn't what I want.
For instance if the user says "I think I would like an apple", the parameters.fruit value is "I think I would like an apple".
Now if a user would say this exact utterance once more a few seconds or minutes later, then the entity $fruit is resolved nicely to "apple" as a parameter to my intent (conv.parameters.fruit = "apple").
How do I configure my intent/entity to always resolve the entity value correctly? This is really frustrating since it's a simple, stupid entity (enum) I'm trying to use. Thanks.
Although I am unable to reproduce your issue, this would be a bug on the Dialogflow side.
Can you try again and confirm you are still receiving this issue?
Also ensure you only have Define synonyms enabled for your custom entities, and that the highlighted portions of all of your training phrases only includes the name of the entity value.
Regardless, I have filed a bug internally to further investigate this issue.
Best,
Related
I would like to perform an action based on a user specific number extracted from a text request: "Open contract number XYZ". Where 'XYZ' is the parameter value I need. There are no obvious boundaries for the content of XYZ. It could be a true number or it could be a string. Can an entity type be based on the term position within the request? I expect dialogflow can match the intent based on the first part of the phrase: "Open contract number". How can I get the parameter value that follows that phrase?
In theory, yes. For this particular use case, you can use the #sys.any system entity. Just make sure to add many training phrases that can help your agent to detect it.
For example:
Make sure to mark the contract numer (or id) in the training phrases, so it can be correctly detected as a parameter.
Now, you can use the value detected in your responses
Example of a detected intent
Keep in mind, that the use of any is not ideal (can lead to unintended behavior); however, if you add a good amount of training phrases and you use contexts to handle the conversation flow, it should work fine.
An additional suggestion. If there's any recognizable pattern in the contract id, you can use regexp entities instead of #sys.any, which will also increase the accuracy.
I have created a pizza bot in dialogflow. The scenario is like..
Bot says: Hi What do you want.
User says : I want pizza.
If the user says I want watermelon or I love pizza then dialogflow should respond with error message and ask the same question again. After getting a valid response from the user the bot should prompt the second like
Bot says: What kind of pizza do you want.
User says: I want mushroom(any) pizza.
If the user gives some garbage data like I want icecream or I want good pizza then again bot has to respond with an error and should ask the same question. I have trained the bot with the intents but the problem is validating the user input.
How can I make it possible in dialogflow?
A glimpse of training data & output
If you have already created different training phrases, then invalid phrases will typically trigger the Fallback Intent. If you're just using #sys.any as a parameter type, then it will fill it with anything, so you should define more narrow Entity Types.
In the example Intent you provided, you have a number of training phrases, but Dialogflow uses these training phrases as guidance, not as absolute strings that must be matched. From what you've trained it, it appears that phrases such as "I want .+ pizza" should be matched, so the NLU model might read it that way.
To narrow exactly what you're looking for, you might wish to create an Entity Type to handle pizza flavors. This will help narrow how the NLU model will interpret what the user will say. It also makes it easier for you to understand what type of pizza they're asking for, since you can examine just the parameters, and not have to parse the entire string again.
How you handle this in the Fallback Intent depends on how the rest of your system works. The most straightforward is to use your Fulfillment webhook to determine what state of your questioning you're in and either repeat the question or provide additional guidance.
Remember, also, that the conversation could go something like this:
Bot says: Hi What do you want.
User says : I want a mushroom pizza.
They've skipped over one of your questions (which wasn't necessary in this case). This is normal for a conversational UI, so you need to be prepared for it.
The type of pizzas (eg mushroom, chicken etc) should be a custom entity.
Then at your intent you should define the training phrases as you have but make sure that the entity is marked and that you also add a template for the user's response:
There are 3 main things you need to note here:
The entities are marked
A template is used. To create a template click on the quote symbol in the training phrases as the image below shows. Make sure that again your entity is used here
Make your pizza type a required parameter. That way it won't advance to the next question unless a valid answer is provided.
One final advice is to put some more effort in designing the interaction and the responses. Greeting your users with "what do you want" isn't the best experience. Also, with your approach you're trying to force them into one specific path but this is not how a conversational app should be. You can find more about this here.
A better experience would be to greet the users, explain what they can do with your app and let them know about their options. Example:
- Hi, welcome to the Pizza App! I'm here to help you find the perfect pizza for you [note: here you need to add any other actions your bot can perform, like track an order for instance]! Our most popular pizzas are mushroom, chicken and margarita? Do you know what you want already or do you need help?
Not able to identify simple phrases like "my name is not Harry, it's Sam".
It is giving me name as harry and company name as Sam, Since name and company name was required in the same sentence.
It should have taken name as Sam and prompted the user again for company name OR should have given complete fallback.
Hi and welcome to Stackoverflow.
Dude. This is not a simple phrase.
Negative questions are always very difficult to catch by Dialogflow.
Suppose I have a question like,
I want to check *google* revenue for the year *2017*
As you can see, google and 2017 are the entities.
But now in the same way if you say,
I don't want to check *google* revenue for the year *2017*
The chances of hitting that old intent is very high as dialogflow matches almost 90% of this sentence with your old sentence. So it might fail.
Hope you are trying to ask something similar to this.
Anyhow coming to your point, If company name and name are different entities, then
Two things you can avoid:
As everyone mentioned,check your entities. The values should not be present in both the entities. This will fail because dialogflow will not know whether it should treat 'Sam' as your name or company name.
If you are not using the values from an entity, instead using '$ANY', then It has a very high chance of failing. And If you are using Dialogflow's system entity like, $given-name, then that is also not preferred as it does not catch all the names. So avoid these entities.
Things you can try:
Train Train And Train. As you would be aware, the training section in dialogflow is pretty good. Train it a few times and it will automatically learn and master it.
But , please note: Wrong training will result in wrong results. It should be 100% accurate. Always check before you approve a training.
And try using webHooks, actions, and/or events to figuring your way out from an external API.
I've made an intent to detect user's answer when they say, for example "when shop is closed" where "closed" is an entity.
When I give the input exactly the same as my training phrase, "when shop is closed", everything is working as expected and and dialogflow correctly detected the intent and the entity value (as shown in the second screenshot).
However, when I input a slight variant to the training phrase, by adding extra words "I think" in front of the sentence, dialogflow still correctly detected the intent, but however this time the parameter value is empty. (as shown in first screenshot)
I will need the value to be detected in both cases, and can't figure out why this is happening.
Screenshot 1
Screenshot 2
Google has published best practices for conversation design here, which should help:
https://developers.google.com/actions/assistant/basics
In this case, have you tried adding, "When is the shop closed?" as a training phrase? Clarifying verb tenses and sentence structure might help Dialogflow correctly identify the parameters you're hoping to extract from a user's given intent.
We’ve been having a great deal of difficulty with chatbot entities over-generalising on Api.ai, i.e. returning values that have not been specified for that entity when using the “Define Synonyms” feature on custom entities, even when the “Allow automated expansion” flag is turned off.
Our key example is an entity we use for confirming a user choice called confirm_accept. We had an entry: “that’s it”, with synonyms: “thats it”, “that is it”, “that’s it thanks”, “thats it thanks”, “that is it thanks”. This entity value was being returned unexpectedly in expressions where just a stray “it” was appearing.
In general, we have seen a lot of inappropriate entity generalisation which seems to indicate there is some form of stop word removal and stemming/lemmatization going on during entity identification... and which can’t be turned off.
This returns poor entity classifications, making it difficult to create entities for which very precise values are important, e.g. where a single word or character can make a big difference in meaning. Our key use case involves a lot of address processing, so it is important we get back only values we have specified.
Types of over-generalisations we’ve seen include:
inappropriate identification of determiners (a, an, the, this, that, etc.) as part of entities: as in “it” returning “that’s it”
stemmed words: as in stray mentions of “driving”, returning “drive” (a valid street type entity)
inappropriate plural stems: a stray mention of “children” returning “child”, or a stray “will” returning “wills” (which in our case “child” and “wills” are street name entities, so we don’t want “children” or “will” to be returned)
This is currently making it difficult to create a production quality chatbot using the Api.ai service.
Anyone had more luck at either getting a response from Api.ai or solving the over-generalisation problem?
Entities are meant to extract information from conversation:
API.AI's entities are meant to be used to extract data from conversational input not parse different phrases and parts of speech. For your examples (that’s it, thats it, that is it, that’s it thanks, thats it thanks, that is it thanks) all seem to indicate that the user's intent is to indicate that the last message from the API.AI agent was correct. For instances like these, it would be best to use these phrases as examples for an intent or an existing intent with other responses indicating that the user wants to indicate that the last response was correct.
API.AI captures entity tenses and plurals automatically: To address your other concern (driving entity, returning drive value, children returning child, or wills returning wills): API.AI intentionally captures different tenses and plurals of entities to provide a better experience for users who many not know the exact entities you've entered in your database. This allows users of your conversational app to have a natural conversation with your users and not require precise wording or