Cisco MindMeld Chatbot Development Framework

And What Can Be Learnt From The Underlying Principles

Cobus Greyling

--

Introduction

MindMeld finds itself in the fold of Rasa in terms of being a complete chatbot development framework which can be installed anywhere.

MindMeld was founded in 2011, acquired by Cisco in 2017. Subsequently, Cisco announced that it was open-sourcing the MindMeld conversation AI platform.

The MindMeld command line interface.

There is quite a bit of activity on the MindMeld GitHub. However, MindMeld 4.3 was released July 2020. The last package was released on October 2020…there use to be a cadence of 2 to 3 packages per year. Seemingly there is a slowing down of releases and packages.

The basic structure of a Cisco MindMeld Conversational AI application. Apps can be seen as an Assistant, Domains as skills. Followed by Intents and Entities.

Installing MindMeld on an Ubuntu instance is straight forward, and an array of blueprint example application are available.

MindMeld is a Python based machine learning framework for Conversational AI. Open-source libraries which are used include Tensorflow, scikit-learn and NumPy.

Elasticsearch is used to power the Question and Answer portion for MindMeld.

Data can be structured in a JSON format, and made searchable by making use of Elasticsearch. This acts as a knowledge base resource available within MindMeld.

Positives

  • Quick and easy to install and get a prototype or demo up and running.
  • Familiar structure in terms of dialog state management, intents and entities.
  • Intents are grouped into domains (more about this later) which acts as a higher first-order pass.
  • Entities are defined contextually with different roles and characteristics.
  • A Number of entity types exist. In this area MinMeld surpasses most frameworks.
  • Opensource
  • Install Anywhere
  • Comprehensive Documentation
  • Dialog State Management is native code; which allows for flexibility and fine-tuning.
  • Asynchronous Dialogue State
  • Python developers will excel.

Not So Positives

  • Training time seemed to take quite a while.
  • New version and package release cadence from MindMeld seem to have slowed down.
  • The Dialog State Management system can become very complex and hard to manage; if not well architected.
  • The Dialog State Management approach is rule based and very rigid. Hard coded and conditional.

Development Framework Concepts

Domains

This is a good piece of innovation, the implementation of domains. A domain is a distinct area of knowledge with its own vocabulary. You could see domains as a collection of intents. Or, intents are grouped into domains.

Consider the example below, with the user input: “please set my alarm to 8am for tomorrow”.

The input:

nlp.process("please set my alarm to 8am for tomorrow")

The output:

{ 'domain': 'times_and_dates',
'entities': [ { 'role': None,
'span': {'end': 38, 'start': 23},
'text': '8am for tomorrow',
'type': 'sys_time',
'value': [ { 'grain': 'hour',
'value': '2019-02-16T08:00:00.000-08:00'}]}],
'intent': 'set_alarm',
'text': 'please set my alarm to 8am for tomorrow'
}

Intents

Intents define the intention of the user; the verb.

For example, the close_door intent, are defined within the smart_home domain, with the following training data:

shut the {bathroom|location} door
{all|all} close now
close {front|location} door
close the {master bedroom|location} door
close my {bedroom|location} door
close the {bathroom|location} door
close the {back|location} door
close doors
close {front|location} door

The grouping of intents under a certain domain is defined by a folder structure. Within the intent example, you can see the entities defined:

{entity_example|entity_name}

Entities

Apart from being defined contextually within the intent example, each entity type has a folder named after it, with a list of training data.

Here is an Example of the Organization of Entities with White List and Canonical Name

There are quite a few Entity Options:

Type

A word or phrase that provides information necessary to fulfill a particular intent. Each entity belongs to a category specified by the entity’s associated type.

For instance, a book_flight intent could have a location type for entities like 'Miami' and 'Chicago O'Hare', an airline type for entities like 'Air India' and 'Southwest', and a date type for entities like 'July 4th' and 'New Years Day'.

System Entity

An application-agnostic entity that is automatically detected by MindMeld. Examples include numbers, time expressions, email addresses, URLs and measured quantities like distance, volume, currency and temperature.

Roles

A label that specifies a sub-category in entities of the same type. Roles are used when identically-typed entities need to be interpreted differently in different contexts.

For instance, in the query ‘Book a flight from SFO to JFK’, both ‘SFO’ and ‘JFK’ are location entities, but they would be assigned different roles: SFO would have the origin role, while 'JFK' would have the destination role.

Entity Group

A group of entities that together form a meaningful real-world concept. Each entity group has one main entity. Other entities in the group (if any) are considered attributes of the main entity.

Other Entities include:

  • Canonical Name
  • Entity Synonym
  • Entity Group
  • Head / Parent
  • Dependent / Child

Dialog State Management

With all the innovation and flexibility MindMeld has in intent and entity management, the dialog state management is very rigid and complex. But native code does introduce a level of flexibility for well engineered solutions.

Primarily, intents are assigned to dialog state names. Each dialog state has a set of conditions which facilitates the dialog flow.

  • MindMeld uses pattern-based rules to determine the dialogue state for each incoming request. Some examples below.
  • MindMeld implements handlers which execute business logic and return a natural language response to the user.
Here are the intents and states in the home assistant blueprint, as defined in the application dialogue handler modules in the blueprint folder. However, dialog states can be trigged by entities or other conditional combinations.

The application logic state can include output data from the natural language processing models, aggregated state from multiple previous interactions, and user and session information.

Each rule specifies what to match, in the following form: exactly one domain, one intent, and a set of entity types.

MindMeld places no restrictions on the code within a handler. This is important because requirements differ for each application, and developers should have the flexibility to organize code as they wish.

As can be seen below, the dialog configuration for the specify_location intent has as few conditions set.

The dialog state management of the intent specify_location. The one-to-one matching of the intent to the dialog state is evident with complex conditions.

Below an example of combined conditional triggers for dialog sates with domain, intent and entities.

from mindmeld import Application

app = Application(__name__)

@app.handle(domain='stores', intent='greet')
def welcome(request, responder):
pass

@app.handle(domain='stores', intent='exit')
def say_goodbye(request, responder):
pass

@app.handle(domain='stores', intent='get_store_hours')
def prompt_for_store(request, responder):
pass

@app.handle(domain='stores', intent='get_store_hours', has_entity='store_name')
def send_store_hours(request, responder):
pass

@app.handle(domain='stores', intent='unsupported')
@app.handle(domain='unknown')
def send_help(request, responder):
pass

@app.handle(targeted_only=True)
def confirm_store(request, responder):
pass

When slot filling is used with multiple entities, the Python code for the intent state management grows rapidly in complexity.

Advantageous of this approach are:

  • Non-propriety in terms of development environment language.
  • Flexible and accommodating to change in scaling (in principle).
  • Non-dedicated, specific skills or specific knowledge required.
  • Porting of code, or even re-use.

Disadvantageousness of this approach are:

  • Design and implementation are far removed from each other.
  • Design interpretation might be a challenge.
  • Another, most probably dedicated, design tool will be required.
  • The complexity of managing different permutations in the dialog still needs to exist; within the code.

Installation

Installation was done using an AWS EC2 instance of Ubuntu 18. The installation steps are listed here…

mkdir /home/ubuntu/mindmeld
sudo add-apt-repository universe
sudo apt-get install -y python3-pip
sudo apt install virtualenv
virtualenv -p python3.6 .
source bin/activate
pip install mindmeld
mindmeld
mindmeld blueprint home_assistant
mindmeld num-parse
python run.py

The sequence of code to build and train the assistant…

from mindmeld.components.nlp import NaturalLanguageProcessor
import mindmeld as mm
mm.configure_logs()
nlp = NaturalLanguageProcessor(app_path='home_assistant')
nlp.build()

And to run…

from mindmeld.components.dialogue import Conversation
conv = Conversation(nlp=nlp, app_path='home_assistant')
conv.say('set alarm for 6am')

Conclusion

MindMeld is the technology behind Webex Assistant, a voice assistant that enables collaboration across Webex Board and Room Kit devices.

MindMeld supports language understanding components of Cisco.com search and its affiliated intranet search sites. Cisco partners and external developers use MindMeld to build successful deep-domain conversational AI agents.

Knowledge base creation and search with Elasticsearch integration. This is seen by Cisco as a big differentiator.

--

--

Cobus Greyling
Cobus Greyling

Written by Cobus Greyling

I’m passionate about exploring the intersection of AI & language. www.cobusgreyling.com

Responses (2)