Building a Chatbot with an Expert System using Grakn at Deutsche Telekom
This post has been written by Klaus Peter Engelbrecht (AI Enterprise Deutsche Telekom AG) and Enzo Martoglio (AI Enterprise Deutsche Telekom UK).
Customer support is increasingly handled by chatbots to improve availability, minimise waiting times for the customer, and reduce customer support costs. While most chatbots today perform simple dialogs during which a customer asks one or more questions that are mostly unrelated, there are some domains that require more coherent dialog behaviour. Here, we present a chatbot in such a domain that we recently built with Grakn. The bot addresses the problem of customer self-service internet connection troubleshooting.
When customers experience problems with their Internet connection, this can be caused by various factors ranging from network failures to wrong connection settings on the client machine. While oftentimes the cause of the problem can be identified by inspecting the status of the router as indicated by several LEDs, customers may consult customer support, e.g. because they have little confidence in their ability to debug a computer network, or because they prefer this to looking up the meaning of LEDs and their statuses in the router manual.
The functionalities expected from a troubleshooting type of expert system can be summarised as follows: Guide the user through the debugging process by asking a series of questions to systematically identify the problem and provide an appropriate solution. This implies the following system requirements:
- Awareness of the meaning of LEDs and their statuses, depending on the router model
- Awareness of solutions addressing each of the possible problems
- Tracking information collected from the user during the dialog, be it explicit (e.g. status of LEDs) or implicit (solutions already tried)
- Inference of the status of the router that is implied by the collected information
- A strategy determining in which order to ask the necessary questions depending on the current information state
A troubleshooting system with such capabilities is ultimately a type of expert system. A limitation of traditional expert systems lies in the complexities of adding and modifying knowledge and ultimately in providing effective ways to map knowledge graphically. As a way to overcome these limitations, we thought to use the Grakn Knowledge Graph architecture as the core of our troubleshooting expert system.
Grakn is an intelligent database in the form of a knowledge graph to organise complex networks of data. The concepts of the systems are entities and relationships, while rules can be added to perform automated reasoning in a distributed environment. Grakn’s schema is a type system that implements the principles of knowledge representation and reasoning, which produce a more expressive and useful system than traditional relational and NoSQL databases when managing large-scale linked data. The benefits of building the expert system with Grakn can be summarised as follows:
- Ease of adding data and representing/modifying rules (with the added benefit of using a database rather embedding all of the above in code)
- Graphical representation of the expert system
- Deductive logical reasoning built-in
- Strongly typed data structures
- Ternary (and N-ary) relationships to interconnect data
With these features, Grakn naturally supports requirements 1, 2, and 4 in the above list. Requirements 3 and 5 would usually be implemented in a dedicated dialog management component. A standard implementation of the dialog manager would be based on a finite state machine, where a state corresponds to a system action, and the next state is reached depending on the user’s response to that system action. Here, in contrast, we propose to model the dialog manager in terms of:
- A dialog state, which is a feature representation of the dialog history,
- dialog state update rules, which define how the dialog state changes depending on the user input, and
- logical inference of actions to be performed by the system given a dialog state.
It turns out that all three mechanisms can be implemented directly in Grakn due to its rule inference capability.
At the heart of our chatbot implementation, a relationship called `diagnosis` is defined, which holds all the information related to the dialog state. In particular, it connects a router-subject, holding information about the LED statuses collected from the user so far, with the user/session identifier and information about the previous system actions ( preceding-action). It also connects an action that holds the next action to be performed by the bot.
Logical inference of actions given a dialog state is implemented using inference rules like the one depicted below. Here, in the “when”-part we match a pattern where information about the router model and two of the LEDs (D-indicator” and P-indicator being green) has been collected, and the O-indicator status has not been acquired yet. When the rule is matched, the “then”-part sets the actionso that the bot asks for the O-indicator.
Finally, additional rules allow us to infer new information about the status of LEDs that have not been asked yet, but are implied by the explicitly specified ones. For example, the below rule states that for the router with name “Speedport W 721V”, the observation that O-indicator has status “GR” implies that D-indicator must also have status “GR”.
The described implementation allows the user to start with an arbitrary troubleshooting request, e.g. “My Router does not work and the Power LED is flashing”, or “The Online LED on my Speedport W 721V is off, what can I do?” The chatbot will then infer the statuses of other LEDs, if they are implied by the available information, and deduct its next action. The action can either be a question about another LED, or it is an attempt to solve the problem by asking the user to perform a sequence of repair actions.
To interact with the bot, we connected it to the Slack bot framework. This required a slim python wrapper to the Grakn database. The interaction currently only uses buttons and selectors. For natural language input, an NLU component would have to be designed. In order to demonstrate the bot’s ability to deal with arbitrary initial requests, buttons triggering the semantic representations of example scenarios were added to the UI.
To conclude, we have presented an implementation of an expert system built on a knowledge graph and a dialog state update-type dialog manager purely based on Grakn. Inference rules were used to model dialog state updates and system action inference. During a dialog, the dialog state lives as a set of facts in the database. This, in theory, allows a deeper integration of dialog management logic and the domain model compared to other approaches. Also, the full power of the Grakn inference engine can be applied to the combined set of facts from dialog state and domain model. We believe that chatbots with an expert system in the backend is a promising direction.
We thank James Fletcher & Tomas Sabat at Grakn for the support for the POC and this article.
Klaus Peter Engelbrecht — AI Enterprise Deutsche Telekom D
Enzo Martoglio — AI Enterprise Deutsche Telekom UK
