How to Get Started with Chatbots — Part 3

Republished By Plato

Followers: 0

Before diving into the ML behind customer-facing chatbots, I’ll first give a quick overview of the system (tl;dr). I will also speak from my experience with Dialogflow, and make the assumption that the approach is similar across other ML-based chatbots.

Basically, everything is built around “Intents” and “Entities”.

Intents: “When an end-user writes or says something, referred to as an end-user expression, Dialogflow matches the end-user expression to the best intent in your agent. Matching an intent is also known as intent classification.”

(definition from Google cloud documentation)

Intent diagram from the same documentation as the quote above

Through intents, the human creating the chatbot defines the possible topics of conversation. With this context provided, the chatbot can refer to fixed responses, once it knows what kind of conversation it is having.

Sometimes, when the chatbot extracts defined parameters, it can respond differently. Let’s take a look at the example above: “What’s the temperature going to be tomorrow in Seattle”.

After the chatbot understands that it’s within the “Forecast intent”, and there is talk of “time” and “location”, the chatbot simply needs to respond with “The weather in <location> will be <forecast> at <time>. ”

See the documentation on Training Phrases for more information

So how does the chatbot recognize which “Intent” it is working within? Well, when you create an “Intent” through Dialogflow, you must provide multiple different ways of asking the question. When you are finished, you tell the system to train on the provided data. I can only assume that there is some sort of Topic Modeling happening here (More info on general Topic Modeling. Although, it’s more likely that, with the limited training data, they’re using an approach that leverages pre-trained vectors).

Entities: “Each intent parameter has a type, called the entity type, which dictates exactly how data from an end-user expression is extracted.”

(definition from Google cloud documentation)

In the example above, we see parameters that are referred to as “System Entities” (date and location); however, it would be difficult (and not very flexible) to define all conversational parameters. So, the “Entity” section allows you to define your own custom parameters. These custom “entities” can now be utilized in responses for the “intents”.

Since “entities” are defined by type and listed out, once the chatbot recognizes the “intent”, it can parse through the words, looking for any that match the list of possible “entities”.

Simply put, with a clean user interface, secure architecture, and modern-day ML, a chatbot boils down to topics, keywords, and context-driven responses.

1. How Conversational AI can Automate Customer Service

2. Automated vs Live Chats: What will the Future of Customer Service Look Like?

3. Chatbots As Medical Assistants In COVID-19 Pandemic

4. Chatbot Vs. Intelligent Virtual Assistant — What’s the difference & Why Care?

When I first thought of how production-level chatbots may work, I expected that the chatbots were coming up with the responses for themselves. Luckily for us humans, they’re not smart enough yet, and we still need to hand-pick appropriate responses, targeting the contexts in which the chatbot can have a productive conversation (customer support, FAQs, etc.)

What I’m referring to as the impractical chatbot is the one built on pure ML. You feed it a training set, and when given novel input, it creates a novel response. This is impractical for a few reasons, but mainly because the chatbot doesn’t have the correct emotional responses to learn from its, or others’, “behaviors”. You can read this Wikipedia article about Tay, created by Microsoft, and manipulated by people on Twitter to become inflammatory, offensive, and racist.

But enough drama, what I find interesting here is that the ML approach to translation can be repurposed into conversation. Conversation can loosely be thought of as people taking turns to speak, where they receive the input of the other, and formulate a response based off of it. The main difference here is that a translation is 1–1 (for all intents and purposes), but a prompt and response can be much more flexible. In this case, you could train the same prompt multiple times with different responses.

One such approach is an attention model, which is so powerful that it can produce results merely with modifications on a feed-forward network. The modification is to include “self-attention” (and you can read more about the calculations here). Loosely, “self-attention” forces each input to have a say. This is fairly sensible when considering how a human approaches translation; it’s not a word-for-word process. In translating one word, you have to look at many other words. The below diagram does a great job at portraying how a machine does this.

Demonstrating the impact of multiple words in translating one word — Figure 3 from this paper

Ok, so when it comes to modeling conversation, mathematicians and software engineers have only come so far. But what about linguists? I’m bringing them into the conversation to scratch the surface of some high-level ideas, looking at where ML approaches are working, and where they can be improved.

Paul Grice, a philosopher, introduced the “Cooperative Principle”:

In social science generally and linguistics specifically, the cooperative principle describes how people achieve effective conversational communication in common social situations — that is, how listeners and speakers act cooperatively and mutually accept one another to be understood in a particular way.

(From Wikipedia)

Assuming that conversation is based in cooperation, he came up with the following maxims. (Again summarized from Wikipedia)