After a first part on the general principles of Dialogflow and on building a high-performing dataset, we’re going to apply all of it to building a conversational agent!

We’ll focus on creating the dataset, and on the traps to avoid. This article, on the other hand, will skip Dialogflow’s integration features, such as context, webhooks, and the nocode Dialogflow CX feature that lets you build and integrate a complete agent without a line of code (well, almost). But don’t panic (the word is very well chosen). We’ll get to that another time!

[So what on earth is this article image? It’s Spin City (with Bender from Futurama), a late-90s show about New York City Hall, very funny, with an absolutely hilarious mayor. But what’s the link between Spin City and Dialogflow? The answer in 6 lines]

LEOBOT !

We’re going to create a dataset for an agent specialized in helping the residents of a small town. The agent will be called Leobot.

Why the name Leobot? Quite simply because Coddity is based in the small town of Saint Léonard de Noblat in the Limousin! (Saint Léo is very picturesque, the people are friendly, and the countryside around it is gorgeous — and there’s fiber)

Architecture

Leobot will be a simple DF agent, meaning it will only do intent detection and entity extraction.

Imagine you’re the mayor of a small town and you launch a chatbot to help your residents with their administrative procedures at the municipality, or to give them practical information. We’ll limit ourselves to a few features: booking appointments, and providing information on the procedures related to the national identity card (CNI). Your bot will be deployed on your website and on your mobile app.

Leobot will be the Dialogflow agent you’re going to use; this agent’s user channel will be your website or your mobile app; finally, all the business logic, the conversational logic, and the booking system will be handled by the site’s backend and the town hall’s information system.

To keep the use cases simple, we’ll assume a user authentication system exists, and that the user is authenticated when a conversation starts.

Obviously, this architecture would change a lot if we used the deep integrations Dialogflow offers. That will be the subject of a future article.

Identifying and segmenting intents

What “business” scope do we want for our bot? The possibilities the bot offers can be summed up in the following 4 user stories, with their corresponding intents (to be created):

• know the town hall’s opening hours INFO-MAIRIE-HORAIRES
• book an appointment at the town hall with a municipal department RDV-RESERVATION
• manage an appointment already booked RDV-GESTION
• get information on identity documents (identity card or passport) INFO-PI

Simple, right? Yeah, no. Not that simple, because what holds for trains holds for NLU intents too: one intent may hide another.

Let’s look in detail at the intents hiding behind these 4 stories.

• INFO-MAIRIE-HORAIRES: no hidden intents. The user wants to know the opening hours of the town hall and of its departments
• RDV-RESERVATION: some users will want to know the available slots, others to book a slot, and even before that, to get information on how to book
• RDV-GESTION: some users will want to reschedule an appointment, others to cancel one, and, as with RDV-RESERVATION, to get information on how to manage their appointment
• INFO-PI: some users will ask for information on obtaining one, others on a renewal, others on a loss

You might object that cancelling an appointment is still a particular kind of changing an appointment, but keep in mind that human beings are going to interact with our agent, and that the more precise our dataset’s intents are, the better the detection. And if you’re worried about the maximum number of intents a Dialogflow agent can address, it’s 2,000. Yes, that’s a lot. So keep calm \o/

[Readers who think fast may tell themselves that, following that logic, you can still find new intents! True, but patience — they show up later in the article]

OK, so our base agent will be made of 9 intents:

• INFO-MAIRIE-HORAIRES: know the opening hours
• RDV-CREATION: book an appointment
• RDV-MODIFICATION-DECALAGE: reschedule an appointment already booked
• RDV-MODIFICATION-ANNULATION: cancel an appointment already booked
• INFO-PI-CREATION: know the steps for creating an identity document
• INFO-PI-PERTE-VOL: know the steps for reporting an identity document lost or stolen

Handling entities

We’re going to identify the entities each intent needs, and identify the ones that have to be custom, meaning created in Dialogflow by us. The first is the one we always run into when it comes to appointment management: the date. Dialogflow has a @sys.date entity that picks up every possible date format users employ. Well, almost every format, because our users can be very creative!

Now, 2 custom entities will be relevant:

• a service entity, to capture the department the user asks for when booking an appointment
• a PI entity, to capture the type of identity document: passport or national identity card

These 3 entities will let us give our information system the data required for the 4 user stories above.

Building it in Dialogflow

Now let’s get practical, and create the dataset in Dialogflow. (This article is not meant to be a tutorial on creating an agent in DF. If you want more detail and an A-to-Z implementation methodology, contact us!)

Creating and configuring the project

The first step is creating the project and the agent via the Dialogflow console. Each Dialogflow agent is in reality a resource you’re going to create on Google Cloud, and each agent will have a reference Google Project ID. To get started, you first have to choose your project’s location from the ones Dialogflow offers. Careful here: this choice can’t be changed later, and it determines where the data in use is hosted. Make it according to your personal-data policy. For hosting under European legislation, you can deploy in the EU-W1 zone, whose data centers are physically located in Belgium.

If you’re curious and you create a project in the US zone, you’ll notice that Dialogflow offers more features than for an agent based in Europe. In particular, a knowledge base for deploying, for example, an FAQ (frequently asked questions) bot (Knowledge), and nocode tools for integrating with conversational platforms such as Skype, Slack, or Messenger.

Now select “Create new agent” in the menu at the top left, choosing its name, the Google Cloud project ID if one already exists (otherwise a project is created automatically), and the language.

Then go into the agent settings, and to the ML Settings tab, to turn on the spelling corrector (which will correct the spelling of sentences written by users) as well as the detection threshold at which Dialogflow will return an answer rather than a “fallback” — that is, the confidence level at which the agent considers its detection good enough.

You’re now ready to create your intents and entities.

Creating custom entities

Before creating our agent’s intents, we’ll start with the so-called “custom” entities, meaning entities specific to our project. Nothing particularly hard. Just click “Entities” in the left toolbar.

Dialogflow lets us turn on 4 options:

• synonyms: let Dialogflow identify an entity value from a corpus of words (synonyms). We’ll use that for the service entity, for example
• regex: typically, applying a regex rule. If you’re not a developer, regexes are rules for capturing information that follows a certain pattern: a phone number, an order number, an invoice number, a reservation number, a reference, and so on
• automatic expansion
• fuzzy matching: this identifies an entity even if the user doesn’t spell it correctly. Very useful on highly specific entities, but it can become a problem if your entity is a fairly common word

“service”

For this entity, and for this demo, we’re going to focus on 6 town-hall departments, using the synonym-definition option: secretariat, voirie, urbanisme, periscolaire, etat-civil, technique.

The agent will identify the entity directly, so the information system can use it to handle the customer’s request correctly, that is, check the available slots in the right calendar and create them.

“PI”

No difficulty here. We just create 2 entity values, passeport and CNI.

Creating the intents

Now we’re going to create the intents, start feeding them with training sentences, and tag entities on those sentences.

In this article we only use Dialogflow’s ability to detect intents and extract entities from them, so we won’t use the context, events, responses, and fulfillment fields. Those will be covered in a future article, so we can make the most of Dialogflow’s power as a conversational platform for building a nocode agent.

Creating the training sentences

We’re at the initialization of our agent, and there are 2 cases: either you have data that can be used to create the training sentences, or you don’t.

What can that data be? > Any sentences written by the future users of your chatbot. For example, if you have a customer-support service over chat, and you want to deploy a chatbot alongside those human teams, you can use the conversations between your advisors and your customers to create the intents’ training sentences. A substantial annotation job is still required to identify the customer’s intent correctly.

Why does this matter? If you followed the first article, the answer is obvious! These are sentences as your users actually say them, and therefore the sentences that will be used on your chatbot. Intent detection gets much easier, because your agent is trained on production data.

For Leobot, we obviously have no data. So we have to let our imagination supply about fifty sentences per intent to get started. We can also use automatic text-generation algorithms.

Here we go!

How do you create training sentences? Careful, this is pretty complicated. You type a sentence into “Add user expression”, and… that’s it. Careful, though: Dialogflow tags entities automatically, and sometimes the automatic identification gets it wrong. On one of our projects, product references were identified as commercial flight references :grimace:.

We’re not going to detail the training sentences here. You’ll find them at the end of the article, via the link to the dataset. Still, here’s the kind of sentence that will make up the dataset. You’ll notice that the sentences contain typos or spelling mistakes: this is very much on purpose. It keeps us as close as possible to the way users interact with the bot (sometimes with mistakes, then).

INFO-MAIRIE-HORAIRES

Quelles sont les horaries d'ouverture ?
Quand la mairie est ouverte?
Horaires

RDV-CREATION

je veux prendre rendez vous avec le maire
je veux un rendez vous car j'ai un probleme
je veux un  rdv pour ma carte d'identité

RDV-MODIFICATION-DECALAGE

j'ai rendez vous la semaine prochaine pour mon passeport mais je veux décaler'
rdv avec la voirie le 5 mars, possible de décaler?
Mon fils est malade, je ne pourrais pas venir à mon rendez vous du 10 avril, je veux reporter

RDV-MODIFICATION-ANNULATION

je veux annuler le rendez vous avec la voirie
je déménage, plus besoin de voir le maire
j'annule le rendez vous du 8 juin

INFO-PI-CREATION

je veux faire une carte d'indentité
comment faire un passeport ?
les passeports c'est à la mairie?

INFO-PI-PERTE-VOL

j'ai perdu ma carte d'indentité
perte du passeport ?
mon fils a perdu son passeport comment faire ?
On m'a volé ma carte d'indentité

Identifying entities

For each sentence you type, you’ll be able to identify entities, whether custom or identified automatically by Dialogflow. For this agent, we can easily identify the entities that will both be said naturally by the user and be useful for giving the customer the right answer. So a user who wants the opening hours of the roads department might say so explicitly in their sentence, and our chatbot’s backend would give them the right answer.

We’re going with the following intent / entity mapping:

• INFO-MAIRIE-HORAIRES: the service and PI entities will make it possible to give the hours of the right department, either by knowing the requested department directly or by inferring it from the PI entity
• RDV-CREATION: entities service, PI, and date
• RDV-MODIFICATION-DECALAGE: entities service, PI, and date
• RDV-MODIFICATION-ANNULATION: entities service, PI, and date
• INFO-PI-CREATION: entity PI
• INFO-PI-PERTE: entity PI
• INFO-PI-VOL: entity PI

To identify the entities, nothing is simpler: highlight the word or expression you want, and Dialogflow takes care of the rest.

Your dataset is ready. Your agent can now train on it, and you can deploy your agent to production!

Hello?

A series of intents is still missing if you want a conversational agent you can use right away. These are what we call small talk: all the little sentences not covered by the bot’s specialization. Saying hello, saying thank you, asking for help, and (unfortunately) insulting it. This last one is actually a rather surprising point, the number of insults a chatbot can receive. Dialogflow offers to integrate some small-talk automatically, but only for certain Google project zones and certain languages.

So you’ll need to create the following simple intents (not an exhaustive list):

• SMALL-BONJOUR
• SMALL-AUREVOIR
• SMALL-MERCI
• SMALL-INSULTE
• SMALL-AIDE

Building them will be a good exercise in using the Dialogflow console!

In the life of Leobot

Our Leobot is going to live its life and meet its users. But your work isn’t done!

Reading the conversations will let you improve its behavior a great deal.

Enriching the dataset

You’ll need to add sentences taken from real conversations to the training dataset, to improve the agent’s relevance. Take care, though, to keep a balance in the number of training sentences across the different intents.

User behavior

First, reading the conversations will tell you about users’ literary style (their syntax, how much they respect spelling). You’ll need to take that into account when you enrich the dataset.

Second, you’re going to see phrasings show up that you didn’t anticipate. For example, in our Leobot’s case, a user is not going to ask specifically for an appointment with the civil-registry department, but may describe their need in other terms:

je veux un rendez vous pour mon pacs
besoin d'un rendez vous pour récupérer un certificat de naissance

These phrasings have to be added to the training sentences, and they also have to push your entity structure to evolve.

Emergence of intents

Naturally your users will say sentences your agent won’t know how to identify (fallback), or will tag with an intent close to the meaning of the customer’s sentence, while being quite incapable of giving the user a correct answer. That triggers a certain amount of frustration.

Examples from our Leobot.

Ou garer ma voiture à la mairie? will certainly be identified as fallback by our agent. It’s up to you to see whether this kind of sentence comes up often enough to call for a new intent, something like “mairie-parking-info”.

Je n'arrive pas à prendre rendez vous avec la voirie will certainly be identified as the rdv-creation intent. The sentence is indeed semantically close to that intent’s training sentences. You then have 2 options:

• add sentences along these lines to rdv-creation (je n'arrive pas à ..., impossible de ... ) but you won’t be able to answer the user’s actual problem, because you won’t have identified it correctly
• create an rdv-creation-probleme intent that captures this user need, with the matching training sentences

That’s all !

Our first version of Leobot is ready! If you want to test it, the agent is available on github. All that’s left is to create an agent on your Dialogflow account and load it in the Export and Import section.

Coming up: an article on measuring performance and improving the NLU engine

THE END