This course will teach you how to create useful chatbots without the need to write any code. Leveraging IBM Watson's Natural Language Processing capabilities, you'll learn how to plan, implement, test, and deploy chatbots that delight your users, rather than frustrate them. True to our promise of not requiring any code, you'll learn how to visually create chatbots with Watson Assistant (formerly Watson Conversation) and how to deploy them on your own website through a handy WordPress plugin. Don't have a website? No worries, one will be provided to you. Chatbots are a hot topic in our industry and are about to go big. New jobs requiring this specific skill are being added every day, consultants demand premium rates, and the interest in chatbots is quickly exploding. Gartner predicts that by 2020, 85% of customer interactions with the enterprise will be through automated means (that's chatbots and related technologies). Here is your chance to learn this highly in demand set of skills with a gentle introduction to the topic that leaves no stone unturned.
Finding and fixing problems
Loading...
Из курса от партнера IBM
How to Build a Chatbot Without Coding
49 оценки
Из урока
Deploying Chatbots to WordPress
Познакомьтесь с преподавателями
Antonio CangianoSoftware Developer and Technical Evangelist
IBM Developer Skills Network
My goal so far has been to show you the fundamental concepts of chatbot building,
and demonstrate to you how by leveraging what's in conversation,
it's possible to build and deploy
a simple but useful chatbot for your own website or business.
If a Floras client asked me to build a chatbot for them,
I would of course spend much more time fleshing out to chatbpt.
I will make it stronger at handling chitchat interactions,
handle more occasions, relationships,
and scenarios in general.
My suggestion to you is to spend enough time to build a solid chatbot for your own site,
and above all to do extensive testing.
Speaking of testing, so far we test
the chalkbot by giving the right answers to the chatbot.
In this module, we'll test the chatbot by intentionally trying to make you fail,
and then discuss strategies to solve those problems.
Pay close attention to how I find these problems by
avoiding to give the answer that the chatbot expects.
The goal of this type of testing is to collect shortcomings.
You can then decide whether a fix is needed for a given failure,
or if it's an edge case that we can agree with.
No chatbot is going to be able to handle every single interaction from the user.
Because this by Florence cognitive capabilities,
we have not built a replica of a human being.
It can be argued, that even a skilled human being could fail at handling some case,
though the resulting rescission will certainly be smother.
Without further ado, let's try to break our chatbot.
We can start by asking for flower suggestions for an anniversary.
And when asked the question on whether it's our anniversary,
we can reply with, "Wait a second."
Florence doesn't understand this phrase.
So we're sent to the anything else node.
Now if we reply yes,
thinking that we are addressing the existing question,
the chatbot waves of goodbye.
That's not really good, is it?
This happens due to a couple of problems or shortcomings if you will.
The smaller problem is that yes on his own is interpreted as a good by intent,
which you rudely concludes the conversation with a user,
when the user didn't actually express the intent to leave.
Yes, we could mark this response as having an irrelevant intent.
We can do so for common cases that we come across,
but we can't realistically mark every possible input as irrelevant.
You may have noticed by now how Watson will quite often interpret
simple vague answers as having a generic intent such as greetings or goodbyes.
This is because by default,
he tries to find the best match among the existing intents,
even if its confidence level in the match is quite low.
We also have a more complex problem.
Our yes was correctly classified as a response types positive,
and the de-value which is good.
But by the time we replied, we were too late.
We were already outside of the anniversary children node list.
So the yes was interpreted out of context if you will,
and treated it as an independent answer and not as a follow up reply.
Essentially, the problem is caused by the fact that
an entity is tied to the current user input,
which in turn is tied to a certain position in the dialog.
In other words, the chatbot knows what to do with the information we collect and
follow up questions only within certain child nodes within the dialogue.
If we get out of the position within a relevant reply like we did,
our reply will be analyzed and evaluated as
if it was a brand new utterance and not a reply.
In short, we have a couple of problems.
Let's proceed in order though by first addressing the generic intent detection problem.
The solution to this problem is accessing and using
Watson's confidence level, for human intent.
Let's start with a couple of examples of the problem.
What time is it in Paris?
And yes, are both wrongly interpreted as adding
greetings and goodbyes intents, respectively.
What we can do, is create a node just below welcome,
and above all other nodes.
Within it we can check how confident Watson is,
that the given input matches the intent that Watson is proposing.
If the confidence level is low,
we'll just jump to the anything else node,
to notify the user that we are not sure about what they are asking.
If the confidence level is higher than the threshold we set,
the condition would be false and Watson will
continue evaluating the other nodes as usual.
This node will essentially act as gate keeper for situations
in which Watson is not confident in the user intent.
Recreate a node as usual.
We give it a name such as Intent Confidence Check.
For the condition we can use,
intents, open square bracket zero,
close square bracket dot confidence less than zero point seven.
What this means, is that we want to check the confidence level of
the first intent in the list of detected intents for the current input.
The number you see between square brackets indicates the position
of the intent that we want in the list of intents.
Quite often the list will only have one intent,
but it's possible to have more than one.
It's at zero rather than one,
because most programming languages start counting indexes at zero rather than one.
This below code you see is Watson conversations SPEL notation,
which also adopts at zero based indexing.
We want to do the jump,
if the confidence level is less than say 70 percent.
So we're checking that a confidence level is below zero point seven.
You can experiment with this number for your own chatbot if you decide to
implement a confidence check or node like I did.
Next, we'll specify that the jump should be towards the anything else node's response,
as an alternative to a jump.
We could have created this node as a parent node,
and place all the other nodes before anything else as these children nodes.
At this stage of the design however,
a jump is just more convenient.
When we test again,
what time is it in Paris, and yes.
Watson recognizes the intent with low confidence,
and therefore would jump to any anything else.
We're told that the chatbot didn't fully understand what we meant, which is good.
As a sanity check,
we can try I and by,
to ensure that they both still work.
In this case, Watson's confidence level is high of course because those
perfectly matched the intent of greeting and goodbye,
so we get the right response as usual.
This change also help us with our second problem.
Let's see how. I'm going to recreate the same scenario as before.
A new serial quest,
wait a second intermission,
and yes as a late answer.
Something is different this time.
Instead of having the chatbot tell us goodbye,
we hit the anything else node because of that gate keeper node that we created.
At this point, the user might be slightly frustrated,
but they will understand that the yes was not understood by the chatbot.
So they might try to ask the question again,
and this time reply yes at the right time.
It's not perfect but it's more user friendly than
cutting the conversation short, like we did before.
Our fundamental shortcoming remains however.
Wanting a relevant reply from the user and we move out to follow up nodes,
which point even a second correct answer will be interpreted as
a standalone question and not a reply to a specific question.
This problem can be solved by using context variables which allow us to
store and access information during the lifespan of a conversation with the user.
So if we assign an entity value to a context viable,
we'll know what the value is at any point during the conversation.
This permits the creation of chatbots.
They're more flexible and much more aware of what information
has been already collected so far from the user.
In turn, this enables the bot to skip
certain questions if the information has already been collected.
In general, context is a very powerful way to preserve state, in our chatbots.
Slots are a new concept,
only recently introduced in Watson conversation.
The leverage context variables,
although they are not strictly a necessary,
they make our lives so much easier,and provide
an elegant solution to the second problem of irrelevant replies.
In the next video, we will focus on context variables and slots.
I'm confident that after learning how to use them,
you'll find them extremely useful in the creation of your own chatbots.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
