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 16 Next »

Dialogflow

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

Read more about creating intents and entities before you start on the DialogFlow: Create an Agent, Intents and Entities page.

Creating a Greeting Intent

Create an intent called greeting in your Dialogflow agent.

  • Add Training Phrases: Add a number of expressions (at least 10) as examples of how a user might greet your agent. Be thorough and try to cover as many phrases as you can come up with. For inspiration, you can do a Google search for greeting phrases. You may find, for example, useful phrases here: 20 Greetings in English. You can also ask ChatGPT to generate example phrases.

  • 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 press SAVE!

Check that your greeting intent is working by using the microphone button in the test console on the DIalogflow console page. Try various phrases also using the test console and check whether what you say is recognized as a greeting intent.

Prolog and Patterns

Greeting pattern without self-introduction

We shall start by considering how a typical greeting pattern looks like. When the agent does not introduce itself, a very common greeting pattern could like look this:

Example:

A: Hello.

U: Hi!

In this example conversation, we see that agent A greets the user and the user U greets the agent in return. We will now try to capture this pattern using the intent we just defined in Dialogflow.

To capture the example pattern, we will use the Prolog predicate pattern([PatternID | Sequence]). Note that this predicate only takes a single list argument, but this list should always have the same structure: the first item in the list should be a PatternID or name of the pattern, followed by a sequence of actor-intent pairs (more on this below).

The first thing we thus always need to come up with when defining a pattern/1 fact is to specify a pattern identification code (ID). For this purpose, we use a systematic taxonomy of patterns with codes for patterns as specified in the book Conversational UX Design: A Practitioner’s Guide to the Natural by Robert J. Moore and Raphael Arar. Greetings are classified as opening patterns by Moore and Arar. A minimal greeting such as in our example is classified as C1.0 in their taxonomy. In our code, we like to avoid the use of capitals and dots too, and we will simply write c10 in our code to refer to this greeting pattern.

The second part of the list we need to add as argument when creating a pattern/1 fact consists of the sequence of dialog moves the pattern itself consists of. A dialog move has two parts: first, we need to specify who makes the move (in our case, the agent or the user); second, we need to specify the type of move made by either actor. As we will classify what agents and users say as intents, we will use intent labels for representing dialog move types. A dialog move then can be represented as a two-element list [Actor, Intent], where the first element Actor is the dialog actor doing the talking (either the user or the agent) and the second element Intent is the intent representing the dialog move type. The first move in our greeting pattern example above thus can be represented by [agent, greeting] and the second move by [user, greeting]. Combining this with the pattern ID c10, the simple and most basic greeting pattern of our example can be represented by the following fact:

pattern([c10, [agent, greeting], [user, greeting]]).

Make sure the labels (names of intents and entities) that you use in your MARBEL agent code are always 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, or other misspellings) may cause issues later on!

We advise using Camel case for intent and entity names, starting with a lowercase letter everywhere (except for the Training phrases that you add).

As mentioned above, this greeting pattern should be used if the agent does not introduce itself by its name. If the agent has a name, we would like the agent to introduce itself. To differentiate between these two cases, we will add a condition to our c10 pattern fact which indicates that it should only be used when the agent has no name (which we will identify with the basic fact agentName(''), i.e. when the empty string is associated with the agent’s name). We then obtain the following complete rule for our basic non-self-identifying greeting pattern:

pattern([c10, [agent, greeting], [user, greeting]]) :- agentName('').

You should add this Prolog rule to the patterns.pl file.

We have used the same name or label greeting that we used for the user’s move also for the agent’s move in the pattern that we defined. This makes sense conceptually because the moves are the same type of move, i.e. a greeting from one actor to another. The same intent label, however, should be handled very differently for the agent than for a user. Dialogflow should handle the natural language understanding (NLU) of a user’s move first by (transcribing the speech and then) classifying the move as an intent. In contrast, the MARBEL agent should handle the agent intent and make sure the agent generates natural language (NLG) text as output for a speech synthesizer. A user’s intent thus can be viewed as an input label whereas agent intents can be viewed as output or response labels. Below, we will see how we can provide texts for the agent to make its move in the responses.pl file. Because the same intent label for a user and for an agent are handled in very different places, there is no harm in using the same label either, and we can keep things conceptually simple.

Specifying the agent’s greeting

In the Prolog file responses.pl we determine what exactly the agent will say to initiate a move in the conversation or how it will respond to something a user said. The basic idea is to add natural language phrases, sentences, or text for each type of move the agent can make. In other words, we need to specify phrases for all the intent labels that occur in dialog moves in all patterns that are made by the agent. If there is no phrase specified at all for one of the agent’s possible dialog moves, the agent will not be able to perform that move…!

We will use the predicate text(Intent, Text) for specifying how the agent will greet a user. The first argument Intent of the text/2 predicate should be instantiated with an intent label in a dialog move of the agent, and the second argument Text should be a string with the text you want your agent to say. For the greeting intent we thus need to specify at least one phrase by adding a text(greeting, "YOURPHRASEHERE") fact to the responses.pl file. Now add such a text/2 fact for the intent label greeting under the % Intent: greeting comment.

If you add only one text/2 fact for an intent label to the responses.pl file, your agent will quickly become boring (if not to your users it will soon enough start to bore you and your team members when you repeatedly need to test your agent!). To enable your agent to vary in what exactly it says when it makes a particular type of dialog move, all you need to do is to add more text/2 facts for an intent. The text_generator/2 predicate defined at the top of the responses.pl file will then randomly select one of these prhases for the agent to say.

Greeting with a self-introduction

Pattern C1.1: Opening Self-Identification (Agent)

Example:

A: Hello.

A: I'm _____.

U: Hi!

This pattern will be quite similar to the one above, but should include the intent label ​​'selfIdentification'. Add a list [_,_] predicate in the pattern list above for the new rule that tells the agent to self-identify. Also, note that the agent must have a name in order to self-identify.

Specifying the agent’s self-introduction

You and your team should think of a name for your agent. Feel free to be creative. We need to tell our agent its name somewhere. In dialog_init.mod2g, on line 40 you can add the name you came up with for your agent. Change the empty string in insert(agentName(''), for example, to insert(agentName('Bellabot').

Next, we need to build the rule for selfIdentification.

The head of the rule should be as follows: text(selfIdentification, Txt) :- 

Place it under % Intent: self-identification in responses.pl

This rule should produce a response that is returned as Txt and should include the agent's name.

Once you have defined your agent you can utilize the predicate that you inserted into its memory.

You should then return a sentence including the agent’s name as Txt.

Visuals

Opening Page (visuals for the c10 pattern)

When a user has visited the Start Page and clicked on the start button, your agent should start talking. The head page(c10, _, Html) for the rule you need to complete has been provided. This page should show your agent’s greeting, and introduce your agent by saying its name!

  1.  Consider the condition that needs to succeed when you generate this page (Hint: look at the start page rule body and how the first parameter of the page/3 predicate is used in that rule).

  2. Think about what you want to be on this page. It needs somewhere to show text to introduce your agent. For this, you can use a card or an alert, for example. This will be the first atom in your HTML code that we use in Step 3. The second atom should be HTML code with text(formatted) to introduce your agent, i.e. what you want to go on your alert or card. In Step 5 we need to format the HTML code by formating the Prolog string with ‘applyTemplate’. This means that in this second atom there should be a placeholder for the variable with the name of the agent. Read the Visual Support Guide for hints on how to do that.

  3. Use a predicate to combine the first atom and second atom you created in the previous step (check out the Visuals Guide for how to do this). What we created in HTML above is our template, and the predicate should return the variable Template.

  4. Now we need to get the agent's name in order to add it to our text. This knowledge should be somewhere in the agent's memory. Hint: Look at line 40 in dialog_init for the applicable predicate. Retrieve the name of the agent in a variable.

  5. Next, you should use the applyTemplate/3 predicate to add the agent’s name to our HTML code atom (which is also explained in the Visual Support Guide).

  6. Lastly, you should use the last variable that you used in the applyTemplate/3 predicate and use the html/2 predicate to convert your code snippet into a completed HTML page. This can be done by using html(YourCompleteHTMLCodeVariableHere, Html). Html is the variable that returns the page as you can see in the head of the rule.

Run It!

To test, go to dialog_init on line 24, put c10 into the agenda, and run your agent. The line should look like this: insert(agenda([c10])). Note that unless the corresponding c10 pattern and response are also completed in the pattern.pl and reponses.pl , your code will not yet work.

Add the c10 pattern to the agenda in dialog_init.mod2g file. If you run your conversational agent, you should hit your start page, press the button, and then your agent should introduce itself. Then you should unmute yourself by clicking the microphone icon in the top left corner, give Google Chrome permission to use your microphone, and return the greeting, by saying hello or anything else you come up with that sounds like a greeting. Check if your agent understood what you said and classified what you said into a greeting intent by inspecting the terminal in which you launched the SIC server:

All done? → https://socialrobotics.atlassian.net/wiki/spaces/PM2/pages/2216001572/Building+Your+Agent#Agent-Capability-2%3A-Specify-Goal-and-Select-Recipes-by-Name

  • No labels