By now, most organizations are realizing that chatbots are something that will be used by customers and employees to interact with the enterprise – whether through voice interfaces including bots like Siri and Alexa or through chat mechanisms like Facebook messenger, slack or skype. But what powers these bots? Clearly their “intelligence” has to come from some source that contains information about products, services, or transactions but how do they learn and how are they developed to serve different audiences, processes or purposes? They need to “know” about your products. They need to “understand” what the user is asking for.
Some will say “that’s what machine learning is for,” or “the AI figures it out.” But how? AI and machine learning are new and powerful ways that computers can write their own programming but that does not happen in a vacuum. We have to begin with something and that something is the data. In a basic example of machine learning, we can show an algorithm lots of examples of pictures of cats and eventually the program learns to identify a cat and distinguish from other animals. What is the equivalent when it comes to a chatbot to support customers?
Well, there are analogous approaches driven by large amounts of data. Given tens or hundreds of thousands of chat interaction examples, some tools can learn from that data and can answer questions in a way that may meet the needs of the user. There are problems with this approach, however. Most organizations don’t have the volume of training data needed for this to be effective. Moreover, a bot built on training data does not always get the right answer. In regulated industries that is not acceptable, and when the goal is to maintain predictable levels of high-quality customer service, too much reliance is placed on the training data. As Microsoft’s ill-fated Tay example illustrated, this can lead to a bot’s “learning” content that is not acceptable by social norms.
In the case of chatbots and voice interfaces, a more intentional, defined, and prescriptive approach is required. But what are the alternatives when designing bots? Two major problems must be solved: the first is to understand what the user wants, and the second to provide that information. In the Alexa world, Amazon refers to these actions as “skills” – the triggers and data sources that allow for functionality.
These skills must be built for the bots that are being created. On the front end, the bot needs to recognize certain elements, such as the name of a product, or the type of information being requested. The bot needs to be smart enough to understand the varying ways that users phrase their requests and extract the main piece of information from the request that then triggers retrieval of the correct information.
Imagine a scenario where a sales person needs to prepare for a meeting with a client. Rather than slog through menus and lists in the marketing content repository, the salesperson asks a helper bot to retrieve the content. The bot could be programmed to recognize the requested content in one of two ways. The bot could ask an open-ended question, or it could provide a selection of choices for the user in advance. From a natural language processing perspective, it is much easier to provide choices. Those choices are defined as part of the structure of the sales collateral. If there are different versions of the content for different industries, the bot can offer up the appropriate choices. The same approach can be used to a find specific piece of content for a specific application, and so on.
Each of these parameters is part of a “knowledge architecture” – the defined structure of information that allows the bot to retrieve exactly the content that the user needs at exactly the right time. The knowledge architecture works on the front end to understand what the user is asking for (looking for specific entities in their utterance or query) and matches it to the back end where content is retrieved.
This same line of thinking can be applied to bots that serve a variety of purposes. Help content, policy information, troubleshooting guides, contract information, and all manner of content can be structured in this way for retrieval. At the end of the day, a chatbot is a channel to information and data, and that data has to be in a form that is useable and retrievable. It also has to be engineered to fit different purposes and contexts.
We can think of bots and intelligent virtual assistants as being on a retrieval continuum. Higher levels of functionality are enabled by layering on capabilities and technologies with a foundational knowledge architecture.
Is this approach always needed? No, there are simple, static bots that can be developed with scripting tools. These bots allow for conversation branching and connection to structured data sources such as account balances. However, some general principles for developing bots need to be considered, whether using knowledge engineering or not.
“Ten Steps to Developing a Chatbot” https://www.aspect.com/globalassets/microsite/nlu-lab/images/10-Steps-to-Chatbot-Creation.pdf by Tobias Goebel, Sr. Director of Emerging Technologies and Lisa Michaud, Director Natural Language Processing at Aspect, describes ten foundational principles for bot development. The question of when and how to use knowledge engineering can impact each of these steps. In the next section of this post, I will explore the first consideration – understanding the role and objective of the bot – and discuss the knowledge engineering considerations.
Determine the Role of the Bot and Set Goals – Bots can be used for multiple purposes, but regardless of their role, they need a carefully defined scope. Narrower is better. Is the bot going to answer a narrow domain of questions and topics, or will it be designed for transactional support? In the case of a bot intended for answering FAQ’s, the top 25 or so questions could be selected. If the bot is used to support transactions or provide status information from a data source, a limited set of use cases can be defined to meet a range of customer inquiries. These types of bots fall into the lower left quadrant of the diagram below, which represents the lowest level of complexity.
When the scope of the bot requires access to greater amounts of more varied information, retrieval can become more complex and nuanced–for example, locating the correct support material for a particular model of smartphone with a specific problem that may vary depending on how the smartphone is configured. The support material needs to be described and cataloged using multiple descriptors including model, problem type and network settings.
If each of these parameters has 10 choices, there could be up to 1000 possible pieces of potentially relevant content to account for each possible combination. Adding more parameters and more choices (through taxonomies and controlled vocabularies) significantly increases the precision of the retrieval process. Expressing this task as a faceted retrieval problem is significantly easier than attempting to write scripts to describe each of the potential scenarios. Trying to do so would be a development, maintenance, and management nightmare.
When a bot requires access to product catalogs and retrieval of associated content such as sales or marketing material, a knowledge architecture is needed in order to organize the content for easy retrieval. The bot can simply ask users what model of phone they own, identify the nature of the problem, etc. For a sales collateral retrieval scenario, using a bot with a well-conceived and designed knowledge architecture allows for a natural, conversational interaction. Whatever the purpose of the bot, well- structured information is needed for it to function well.