Dialogflow

Removing feature requests again

Users, of course, should not only be able to add recipe preferences but, when recognizing, for example, there are few or no recipes to their liking that meet the preferences they expressed, should also be able to remove them again to look for other options. They should, for example, be able to say 1. “I wish to remove the preference for vegetables”, 2. “Forget about excluding broccoli”, and 3. “Can you delete the cuisine preference?”. Of course, they could already get rid of these filters by expressing the opposite, and say, for example, “I would like recipes with broccoli”. However, instead of simply removing the constraint to exclude broccoli, that would also introduce a preference for recipes with broccoli (it is useful to better understand this point to check again how the removal of conflicting requests has been implemented in the ingredient_hierarchies.pl file).

...

To be able to make sense of user requests asking to remove a value or a filter type, you should add two new intents to your Dialogflow agent. Call the first one deleteFilterValue and the second one deleteParameter (for the latter intent, the name stems from the fact that Dialogflow calls the entity types that have been supplied by the end-user parameters). Making these intents robust, i.e. for ensuring that the potential endless variety of user expressions will be recognized by your agent, you should add training phrases for all the different entity types and parameters/features/filters that a user could ask the agent to delete.

You should annotate the training phrases for deleteFilterValue with existing entity types but use different parameter names to indicate that the values captures should be removed from the feature requests stored in the agent’s conversational memory. You tag the entity in your training phrases as you did before (e.g. using @ingredient) but then you should change the parameter name to something of the form entitynameDel (we suggest adding Del at the end of each parameter that you already have to facilitate relating them to each other). So, for example, you would add new parameter names for ingredientDel, cuisineDel, durationDel, etc.

For the deleteParameter intent, you should introduce a new entity type called @filterType (with corresponding parameter name) and add as entry entities all the features you have introduced, such as ingredient, cuisine, etc. You may also wish to consider any synonyms that a user might use to refer to any of these features. Again, make sure to include a sufficient number of training phrases to make recognition of this intent robust.

Expressing that you are done

A user should also be able to say it does not want to provide the agent with more information to go on (which does not mean the agent should accept that in all cases!). As we have implemented things thus far, we would expect a user to respond negatively to an agent request to elaborate on what they are looking for:

A: Can you elaborate on what you're aiming for in your recipe?

U: I don't want to add anything else.

Recall that we used the agent intent ackFilter to implement the first move in this fragment as part of the a21featureRequest pattern. If a user complies with the agent’s request, that would trigger another a21featureRequest pattern. If a user does not comply but rather responds negatively, we can also view that as a disconfirmation move. We argue that we can reuse that intent to capture negative responses to the agent’s request. A user, for that matter, could also simply respond to the agent’s move by saying “No, I won’t” or something similar. We implemented this intent before, but we should extend it to now also cover the variety of user expressions a user could use to say they do not want to add anything else. So, you should add training phrases to make sure these expressions are covered too.

Prolog and Patterns

We will begin with implementing a pattern for allowing a user to express they are done, and then get back to what is still missing to implement requests to remove a filter.

...

There is still one thing missing… Just by talking the agent will not change the page that is displayed. Recall that you have created two pages for the a50recipeSelect pattern for Capability 5: Filter Recipes by Ingredients and Cuisine https://socialrobotics.atlassian.net/wiki/pages/createpage.action?spaceKey=PM2&title=2025%20Capability%205%3A%20Filter%20Recipes%20by%20Ingredients%20and%20Cuisine. When the agent grants the user’s request we still need to make sure that the second recipe recommendation page showing the recipe pictures is displayed. To make that happen, we need to change the condition for showing that page. We need the store the fact that the user requested this. The idea is to use the conversational memory of the agent for that and update it with this information. Therefore, when the agent grants the user's request, the version of that pattern should end with the agent updating its memory using an [agent, update(['show'='true'])] actor-intent pair. To change the condition for showing the page in the html.pl file, we can then use the memoryKeyValue/2 predicate defined in the dialog.pl file to add an alternative condition for showing this page.

...

This completes the implementation of all the different cases for the agent’s response. The patterns for removing filters should now work!

Visuals

What you do visually for this capability is up to you.

Test it Out

Now Run your Conversational Agent https://socialrobotics.atlassian.net/wiki/pages/createpage.action?spaceKey=PM2&title=2025%20Run%20your%20Conversational%20Agent again and try to remove some of the recipe constraints after you added them.