Credit to Kjpargeter Images (via onepixel.com)

How easy is it to build useful chatbots? Do you need programming skills? In part 1 of Do you need to be a programmer to build a chatbot? I provided an evidence-based answer to this question by racing through a simple real-world example of using Google Dialogflow (a typical chatbot builder tool) to implement just the first two questions and answers from a mobile device troubleshooter chatbot. And, yes, this showed you need to be a capable programmer to build a non-trivial chatbot.

So the next question is — what do you need to build ‘happy paths’ of more than just two questions and answers? To add deep expertise? To enable users to chat with experts instead of a sales assistants? There’s a clue in the banner image of this article. You need a chatbot power tool!

The story so far…

Using Google DialogFlow to implement just the first two questions and answers in our example mobile device troubleshooting chatbot required 48 inter-connected intents, with a bunch of associated entities, training phrases, webhooks, actions, parameters and contexts.

To avoid repetition I’m going to assume you’ve read part 1 of this article. Like a TV mystery series this episode won’t make sense without its back story.

eXvisory start action — handing over to eXvisory deep logic

A typical troubleshooting chat requires many more than two questions and answers, which would mean adding thousands more intents if we continued with the same approach. So part 1 ended with our wily mobile troubleshooter handing over to an eXvisory deep logic webhook, passing it the exvisory.start action and triage parameters gathered by the first two questions.

The mysterious webhook

All subsequent troubleshooting questions, and the order in which they are asked, are now handled by one exvisory.answer intent.

eXvisory.answer intent

The exvisory.start action returns from the eXvisory webhook with the next troubleshooting question and a new context_exvisory context (see part 1 for explanations of all these terms), which effectively means the conversation has exited the triage phase and entered the eXvisory phase.

All answers to questions returned by the eXvisory webhook will be matched by the exvisory_answer intent — for two reasons. One is that exvisory_answer is one of only a handful of new intents associated with the context_exvisory context (others handle user digressions during the eXvisory phase, for example asking for help how to answer the last question). Two is that the DialogFlow training phrase @sys.any:answer means “match any input text and assign it to a parameter called answer”. This answer parameter is passed back to the eXvisory webhook along with the exvisory.answer action, which again returns context_exvisory and the next question, and so on and so forth until the conversation completes.

But how does the eXvisory webhook work?

eXvisory deep logic networks

It’s not magic, and it still requires programming skills, but the eXvisory deep logic editor is the power tool of chatbot building!

eXvisory deep logic network editor

This is what the eXvisory deep logic editor looks like. It models business logic at a much deeper level than crude decision trees or graphs. For example, for troubleshooting applications (the initial focus of eXvisory.ai) it models the process of elimination.

To use it you select rules from a palette of 5 logic rule types, fit the rules into the cyan and blue hierarchy on the left, then configure each rule using the JSON editor on the right. It’s like solving a jigsaw puzzle, because it’s obvious how the rules should fit together (more later). Every time you press Save the editor regenerates a cloud-hosted eXvisory deep logic webhook which automagically asks the right questions in the right order! But perhaps the biggest benefit of eXvisory deep logic networks is that their complexity does not increase exponentially with the number of rules. In fact, complexity hardly increases at all. In the screenshot above it’s as easy to understand, extend and test the whole cyan and blue deep logic network as it is to understand, extend and test the smaller highlighted portion.

How it works

Let’s see how it works by looking at real-world examples of how we used the eXvisory dev tool to add deep logic rules to our mobile device troubleshooter chatbot to find and fix WiFi hotspot problems.

hotspot fault group (and sub-faults)

Take a closer look at the deep logic network. It’s a fault containment hierarchy and it reads from left-to-right and then from top-to-bottom, which is the order in which it is evaluated — or the order of inference. Starting at the top left it’s easy to read, because it’s effectively saying all device faults are … well, device faults. But device faults can be split into network, or connectivity, or app or other sub-faults. Then connectivity faults can be split into conn_wireless (wireless connectivity) or conn_usb (wired connectivity) faults. Then conn_wireless faults can be split into bluetooth or hotspot faults. And so on and so forth.

The cyan nodes are fault groups, which model groups of related faults (related symptoms, related troubleshooting procedures). The blue nodes are faults, which model specific faults that can be found and fixed. It’s your job as an eXvisory developer to identify these faults and fault groups and fit them into the hierarchy. Faults are easy, because they usually correspond to cases someone has found and fixed before. Fault groups are a little harder — and there is no one right way to lay out the hierarchy — but neither is it very hard and you can use drag & drop to move nodes around. In fact, ‘laying out’ a new fault containment sub-hierarchy (for example when we added the hotspot fault group and its sub-faults) really helps organise your thoughts.

Puzzle piece 1: Fault groups

I’ve zoomed in below on the hotspot fault group. It ‘contains’ faults and other fault groups. The contained fault groups are to do with the WiFi hotspot not being enabled (hotspot_not_enabled) or the problem being with the client device trying to connect to the WiFi hotspot (hotspot_client).

hotspot fault group

On the right is the JSON configuration for the hotspot fault group. JSON is a popular human-readable format and it says that the selected fault group is called “hotspot” and includes a developer comment, an ordered list of its sub-faults (faults or fault groups) and a “scoped” text resource that is shown to the chatbot user if the fault is scoped to this fault group (see later).

Puzzle piece 2: Faults

Below is the hotspot_plan_tether fault. Its JSON configuration has a couple more clauses. The conditions clause says run a test (the third type of logic rule we’ll look at next), which asks the user if their cellular data_plan allows tethering and stores the results in the variable ?tethering. The result clause is a logic expression (which evaluates to TRUE or FALSE) that says it must be a hotspot_plan_tether fault if ?tethering is NOT available. The “found” resource would then be displayed by the chatbot.

hotspot_plan_tether fault

Puzzle piece 3: Query tests

This is the data_plan tethering test used in the hotspot_plan_tether fault. It’s a query test because it asks the user a question. If you look through the JSON configuration you’ll see it wants a yes or no response and has text resources for the question “prompt” and “help” shown to the user.

data_plan tethering query test

Looking closer at the resources you’ll see they can refer to the results of previous tests, like {{cell_provider}}. In this case the conditions clause requires the cell provider test (which asks the user for the name of their cellular provider) to be evaluated before the data_plan tethering test.

Puzzle piece 4: Synthetic tests

Synthetic tests combine other tests to deduce new facts. The browser activity synthetic test shown below uses its conditions clause to evaluate the browser https_public and browser http_public tests (which ask the user if they can browse to secured or open web sites) and then logically combines their results so that browser activity is TRUE if either test succeeds.

browser activity synthetic test

Puzzle piece 5: Eliminators

I’ve saved the most important logic rule to last. Eliminators eliminate or scope a fault group. Remember that inference proceeds through the deep logic network from left-to-right and top-to-bottom. Imagine inference has reached the hotspot fault group. What would be the ideal question to ask the user at this point?

hotspot eliminator

If I could run a test that would eliminate hotspot from consideration that would be very handy, because in one fell swoop it would also eliminate all of hotspot’s sub-faults (the highlighted portion of the screenshot). Even better, if I could run a test that would scope the fault to belong somewhere within hotspot and all of its sub-faults then it would eliminate all the (non-highlighted) nodes outside hotspot. That’s a lot of nodes!

Check out the JSON for the hotspot eliminator. Its conditions clause runs a connectivity type synthetic test that returns the type of connectivity problem being experienced. The result clause then says hotspot can be eliminated if the problem is unrelated to WiFi hotspots, or scoped if it is.

Putting it all together

That’s a lot of new concepts, but it’s surprisingly simple. You identify faults and fault groups, fit them into a deep logic network (in this case a fault containment hierarchy) and inference flows through the hierarchy from left-to-right and top-to-bottom. This triggers evaluation of fault group eliminators, which in turn trigger query and synthetic tests referred to in their conditions clauses. Depending on the results of these tests (query tests correspond to the chatbot asking the user questions) large swathes of the deep logic network are eliminated, so the chatbot only ever asks the most relevant questions. As you fit logic rule puzzle pieces into the deep logic network jigsaw it automagically asks the right questions in the optimal order!

And your deep logic network is immediately available as a cloud-hosted webhook you can use to add deep logic expertise to your chatbot. We provide sample code for integration with Google DialogFlow (it only requires a few additional intents) and can easily support any other webhook-enabled chatbot frameworks. So please contact eXvisory if you’re a chatbot developer and early adopter looking for new and more lucrative projects — like building troubleshooting chatbots for major product companies!

If you enjoyed this article please recommend it to others by clapping madly or leaving feedback (below) and sharing or linking to it.


How do you add deep logic (expertise) to a chatbot? was originally published in Chatbots Magazine on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source link