Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

Create an agent and Read about How to Make Intents and Entities:

DialogFlow: Create an Agent, Intents and Entities

Before you start: make sure your MARBEL agent is connected to Dialogflow:

Dialogflow: Connecting Dialogflow Agent to MARBEL Agent

Make sure the labels (names of intents and entities) you use in your MARBEL agent code are exactly the same as the intents and entity entry names that you have specified in your Dialogflow agent! Small spelling mistakes (e.g., using capitals or not, other misspellings) will cause issues later on! We advise to use https://en.wikipedia.org/wiki/Camel_case starting with a lowercase letter everywhere (except for the Training phrases that you add).

Greeting Intent

Make an intent called ‘greeting’.

  • Under ‘Training Phrases’ add a number of expressions (at least 10) by which a user may greet - try and be thorough. For inspiration, do a https://www.google.com/ search for ‘greeting phrases’. You may find, for example, useful phrases here: https://www.tandem.net/blog/20-greetings-in-english.

  • Under ‘Action and parameters’ make sure the box above the table is filled in with the name of your intent as shown in the image below.

Don’t forget to SAVE!

Check that your ‘greeting’ intent is working by using the microphone button in the test console.

Appreciation, Confirmation, Disconfirmation, Farewell Intents

Add the following intents, following the same procedure as you did for the ‘greeting’ intent. Use the intent names as specified below:

  1. appreciation

    1. If a user expresses appreciation or gratitude, for example, ‘thanks’.

  2. confirmation

    1. If a user wants to agree or say ‘yes’.

  3. disconfirmation

    1. If a user wants to disagree or say ‘no’.

  4. farewell

    1. If a user wants to say 'goodbye'.

  5. checkCapability

    1. the intent that represents a user querying what your agent can do. An example phrase would be “What can you do?”.

Fallback Intent

The Default Fallback Intent is one of the more important intents. It is already available when you create your Dialogflow agent. A fallback intent is triggered if a user's input is not matched by any of the other intents known by the agent, or if it matches the training phrases you input for this intent.

It is not necessary to add phrases that are completely unrelated to the topic of our recipe recommendation agent, as these would definitely come back as an unknown intent. Thus, what you should do is think of related phrases that would be close to an intent but should not match with it. For example, “I do not like mushrooms” is food related and refers to an ingredient entity ‘mushroom’. Yet, you might argue that it should not be matched to any of the intents you specify, because you do not want users to discuss their likes and dislikes with your agent. Alternatively, you could also argue to include ‘I like’ and ‘I dislike’ as training phrases for filtering by something. But that is a design decision for you to make! The Fallback Intent should be updated as you add more intents throughout the project.

Entities

Before you can continue creating intents, you have to create the entities you need, since these will be part of the intent specification for certain entities (e.g., the presence of an entity type is used as a feature by the Dialogflow classifier model to recognize certain intents by). Some of these entities have already been provided to you. For information on how to upload and create entities, please read this page: DialogFlow: Create an Agent, Intents and Entities.

Some entities have not been provided with the agent project. You have to add them yourself (see the list below). We provide an example for most to make sure you have at least a few entries for each entity. They may not be that intuitive at first, so make sure to extend the entity specification with more synonyms as your agent evolves.

If the word you enter for an entity entry has synonyms, enter these as synonyms rather than adding these as different entity entries!

  1. removeKeyword - words to remove filters (for example ‘remove’)

  2. timeKeyWord - words that refer to measurements of time (hour, minutes, etc.)

  3. shortTimeKeyWord - for example ‘fast’, ‘quick’ etc.

  4. negationKeyword - to specify that something needs to be omitted (for example ‘without’ or ‘don’t’)

  5. easyKeyWord - to specify recipes that are not hard to make (for example ‘simple’)

When you are done your entities page should look as follows:

The ‘addFilter’ Intent

The intent for filtering recipes is one of the most important intents. It is used to filter recipes for the user based on a variety of criteria. This is the first intent that employs all the entities we have created. In the user expressions, where the user is asking to filter, all different entities need to occur and be tagged in the set of examples. For example, for a training phrase like “I want a Chinese recipe”, ‘Chinese' needs to be tagged as ‘cuisine’, so this phrase can be parsed by Dialogflow in order to apply the filter ‘cuisine’ to the recipes in our database. The ‘addFilter’ intent can be found in the folder provided to you, and should be uploaded in Dialogflow by you.

Recipe Filtering Helper Predicates

To filter the recipes for the user in the way they intend, their utterances are mapped onto the intents and entities you specified in Dialogflow. This then returns the identified intent (for example, ‘addFilter’) and entity information (for example, cuisine - ‘Chinese’). The MARBEL agent must be able to use this information. In order to make this happen, you need to create Prolog rules to filter the available recipes in the Prolog database. This can be done by introducing the following Prolog predicates. We have already specified the heads of all rules in the recipe_selection.pl file. That is where you still need to add the bodies for these rules. We need a few helper functions before we can start implementing code for filtering, which are described next.

nrOfIngredients 

We will start off easy. 

nrOfIngredients(RecipeID, N) :-

Create a rule to return N, the length of the list of ingredients for a certain RecipeID. HINT: your Visual  Support groupmates should have made an ingredients function that could help. 

nrSteps 

nrSteps(RecipeID, N) :-

Create a rule to return N, the number of steps for a certain RecipeID. HINT: your groupmates should have made a recipeSteps function that could help. 

diet

diet(RecipeID, DietaryRestriction) :-

In the diet rule, we need to find all the ingredients that a certain recipe has and then input them into a new function we shall create below diet, called ‘ingredientsMeetDiet’. This function should return a list of ingredients that fit the dietary restriction. This list should be returned with the name DietaryRestriction.

ingredientsMeetDiet([ Ingredient | Rest ], DietaryRestriction) :-

The ingredientsMeetDiet predicate is our stop clause, which will recursively check each ingredient and return ‘false’ when an ingredient does not meet the given dietary restriction. The predicate ‘typeIngredient’ can be used to check if an ingredient meets a dietary restriction. Fill in the body of the rule for ingredientsMeetDiet. 

easyRecipe

easyRecipe(RecipeID) :-

Make a rule that can return all easy recipes. 

 A recipe is easy when:

  • it can be made within 45 minutes, 

  • it has less than 18 steps, and

  • it has less than 15 ingredients

Recipe Filtering Predicate

You will now introduce a predicate applyFilter/4 for filtering recipes that returns a list of filtered recipes in the form of their RecipeIDs. Again, the heads of the rules that you need to define are in the recipe_selection.pl file.

There are a number of different rules that you need to implement for the applyFilter/4 predicate, depending on the specific filter that needs to be applied. For example, filtering recipes for a cuisine asks for a different rule than filtering for the duration of a recipe. These variants are specified in the table below.

applyFilter

applyFilter(+ParamName, +Value, +RecipeIDs, -FilteredRecipes)

Filters the recipes provided as input using the (Key) feature with associated value and returns the recipes that satisfy the feature as output.

  • ParamName: A parameter name referring to a feature that the recipes should have (for example: ’cuisine’).

  • Value: The associated value of the recipe feature (for example: ‘Chinese’).

  • RecipeIDs: The recipes that need to be filtered.

  • FilteredRecipes: The recipes that have the required feature.

Thus, you must find all recipes that fit the filter criteria and return a list of the filtered recipes. Make sure to use the naming conventions for the variables that we provided. For the first two functions, we shall provide some hints. These hints could apply to more than one ‘applyFilter’ rule. The heads can be found in recipe_selection.pl.

A list of all your ‘applyFilter’ functions and some notes on how to create them:

Predicate Description

Rule Head

Notes/Instructions

The predicate to filter recipes on cuisines (e.g., Italian recipes) 

applyFilter('cuisine', Value, RecipeIDsIn, RecipeIDsOut) :-

  • The input Value, in this case, is a string Value, and to make sure it compares to what is in the database we need to make sure it is all lowercase. You can do this with ‘downcase_atom’.

Predicate to filter recipes that meet the dietary restrictions (such as ‘vegetarian’).

applyFilter('dietaryrestriction', Value, RecipeIDsIn, RecipeIDsOut) :-

  • This rule should filter recipes based on their membership to dietary restriction. To check if a recipe is a member of a dietary restriction you can use the built-in Prolog member/2 predicate.

  • (member(Recipe, List of Recipes), diet(Recipe, List of Recipes in Diet))

Predicate to filter recipes on the max amount of time

applyFilter('duration', Minutes, RecipeIDsIn, RecipeIDsOut) :-

  • Your condition/goal will ideally have three components, one of which is member/2

Predicate to filter easy recipes

applyFilter('easykeyword', _, RecipeIDsIn, RecipeIDsOut) :-

  • You made a rule for this!

Predicate to filter recipes on the exclusion of a specific ingredient 

applyFilter('excludeingredient', Ingredient, RecipeIDsIn, RecipeIDsOut) :-

  • There is a predicate in ingredient_hierarchies.pl which one could consider useful

Predicate to filter recipes on the exclusion of a specific ingredient type (for example: ‘beef’)

applyFilter('excludeingredienttype', Ingredient, RecipeIDsIn, RecipeIDsOut) :-

  • The body of this rule is similar to the ‘exclude ingredient’ rule (the difference between ingredient and ingredient type is catered for in ingredient_hierarchy.pl)

Predicates to filter recipes on a specific ingredient inclusion

applyFilter('ingredient', Ingredient, RecipeIDsIn, RecipeIDsOut) :-

  • Do your best!

Predicate to filter by including an ingredient type 

applyFilter('ingredienttype', Ingredient, RecipeIDsIn, RecipeIDsOut) :-

  • The body is the same as the ingredient rule above

Predicate to filter recipes on meal type (for example: breakfast)

applyFilter('mealType', Value, RecipeIDsIn, RecipeIDsOut) :-

  • Downcase_atom the Value input for compatibility 

Predicate to filter recipes on a maximum number of ingredients

applyFilter('nrOfIngredients', Value, RecipeIDsIn, RecipeIDsOut) :-

  • Value inputs are an atom/string, check utils.pl

Predicate to filter recipes on a maximum number of steps

applyFilter('nrSteps', Value, RecipeIDsIn, RecipeIDsOut) :-

  • Do your best!

Predicate to filter recipes and return fast recipes. A recipe is fast if it takes less than 30 minutes 

applyFilter('shorttimekeyword', _, RecipeIDsIn, RecipeIDsOut) :-

  • Do your best!

Predicate to filter on the number of servings 

applyFilter('servings', Value, RecipeIDsIn, RecipeIDsOut) :-

  • Do your best!

Predicate to filter recipes on a tag (for example: pizza) 

applyFilter('tag', Value, RecipeIDsIn, RecipeIDsOut) :-

  • tag(RecipeID, Value) could be useful in your goal 

Further Necessary Intents

deleteFilterValue 

‘deleteFilterValue’ is useful to deal with a scenario where the user requests to remove a filter that they have already put on specifically. For example, “I wish to remove the onion filter”, “Forget about excluding broccoli”, and “Can you delete the Chinese cuisine”. 

It is thus important that in your training phrases you include a variety of entities and that these entities are also given specific values and parameter names in the Action and Parameters tables. Your entity table under Action and Parameters should look like this when you are done. 

deleteParameter 

The ‘deleteParameter’ intent is identified when the user requests to remove a kind of constraint. For example, “I wish to remove the ingredient constraint”, and “Please drop the step constraint”. This intent requires the use of a certain entity. Make sure to include it in your action and parameters section. 

noMoreFilters 

The ‘noMoreFilters’ intent is used when the user does not want to add any more filters to their recipes list and wishes to see the available recipes. 

recipeRequest

‘recipeRequest’ is used to confirm the user's choice of recipes (“I want this specific recipe name here”). Under Entities, you can find an entity for the recipe names in our database.

In the end, your Intent page should look like this:

You have reached the end of the basic implementation of the Natural Language Understanding and recipe filtering code for your recipe recommendation agent. Make sure to properly test each intent, entity and rule that you have implemented. For how to do this check out the Agent Testing section.

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.