Author: joekozhaya

Watson Conversation with Alchemy Entity Extraction

Overview of Watson Conversation

Recently, there’s been an increased proliferation of bots in various applications and platforms to address various needs from ordering pizza, to booking a flight, to providing customer support. The Watson Conversation service recently became generally available to offer developers a turnkey service for building bots and virtual agents. If you haven’t tried it already, I strongly encourage you to take it for a test drive by either checking the demo and browsing the documentation or better yet, by building your own bot. To build your own chatbot or virtual agent, you’ll need to sign up to Bluemix (it is free for 30 day trial), IBM’s platform as a service solution and the environment through which you can provision any of the Watson services including the Conversation service.

To best understand the Watson Conversation service, it is best to focus on its three constituent components: Intents, Entities, and Dialog.


The purpose of intents is to map “what a user says” to “what a user means”. Because of the wide variety of utterances users say to mean the same intent, Watson Conversation leverages deep learning technology to extract intents from utterances. You, as the app developer, have complete control in defining what intents are relevant to your application. Once you’ve defined your list of intents, you need to teach Watson how to recognize these intents by providing it with sample utterances and how they map to these intents. Probably the most common question we get from developers is “how many sample utterances do I need to provide”. While the tool requires a minimum of five sample utterances, the general guideline is “the more the better”. We’ve typically seen good results with 20-30 sample utterances per intent. The key observation is to try and capture real end-user input utterances and then map those to the intents you’ve defined for your application.


Entities, on the other hand, provide specific information that your bot can leverage to provide most relevant response. For example, if the user’s utterance is “I would like to book a flight to Paris”, then the intent is “book_flight” and the entity is “Paris”. You, as the app developer, define the entities that are relevant for your application by providing a list of entity names and for each entity, a list of values and for each value a corresponding list of synonyms.


Once intents and entities are defined in the Conversation service, it is the Dialog that actually orchestrates the conversation based on extracted intents and entities, as well as context provided by the application. Context is an extremely important concept as it is the bridge that links the conversation service to your bot (or application). Any information communicated back and forth between the Conversation service and the bot goes across through the context variables. Dialog consists of a number of user defined nodes where each node executes based on whether its condition is true. Think of each node as an “if” condition where the condition checked is based on a combination of intents, entities, and context variables (or any derived variables). If the condition is true, then the node executes; if not, the flow continues to the next node in the dialog. Please note that the order of the nodes is important as the flow executes top to bottom, left to right.

Integration of Conversation with Alchemy Language

In the rest of this blog, I’d like to focus on a very common question I get from partners and clients: “How can I integrate conversation service with another service such as Alchemy Language to extract relevant entities from the user utterance”. Once you’ve experimented with Conversation service, you’ll love how intuitive and simple it is to create powerful bots but you’ll probably express the same need above.

Currently, you have two options in extracting entities from user utterance:

  • You define the list of value entity values and synonyms in the conversation service.
  • Your application manages the extraction of relevant entities and passes those as context variables to the conversation service.

While the first option is quite easy to implement, it does require providing an extensive list of entity values. The second option, on the other hand, allows you to leverage another service to extract relevant entities in your application and pass those along to your conversation service.

To illustrate the second option, we will start with the cognitive car dashboard sample application. Before proceeding, please follow the steps in the cognitive car dashboard conversation-simple application and make sure you have it running locally per the instructions. Once it is running, you will see the initial prompt from the application:

Screen Shot 2016-08-27 at 12.24.52 AM

Go ahead and type in the following utterance to ask about the weather in Austin today.

Screen Shot 2016-08-27 at 12.27.08 AM

Verify that you get the following response:

Screen Shot 2016-08-27 at 12.28.19 AM

Note that the application understood you are asking about the weather but it hasn’t been updated to actually look up the weather based on your input. We will update the conversation service and the application to be able to respond to such input utterance. Specifically, we’ll update the application to extract relevant entities (in this case, we mainly care about City where weather is requested) and then pass those entities to the Conversation service via the context variable. To do so, we will leverage Alchemy Language entity extraction api.

All the code changes are available in joe4k/conversation-simple github repo which was forked from original conversation-simple repo. For reference, here is the code change required. First, we need to add service wrapper for Alchemy Language (as shown below) which requires an api key to authenticate to the service. You get the api key by creating an Alchemy Language service on Bluemix; once created, the credentials will provide the api key. If you need more details on how to create Alchemy Language service, check out this AlchemyLab with code uploaded to github.

Screen Shot 2016-08-27 at 12.31.10 AM.pngNext, we will modify the code to first call Alchemy Language entity extraction on the input utterance, update the context variable with extracted entities, and then pass the input + context to Conversation service.


Screen Shot 2016-08-27 at 12.31.47 AM.png


Screen Shot 2016-08-27 at 12.33.41 AM.png

Next step would be to update the Watson Conversation service to perform some action based on the context variable appCity. As you can see in the Modified version below, we’re adding an extra node after intent is identified as #weather to check if the city context variable is defined. If it is, then Conversation service responds indicating it will provide the weather for that city. If not, it requests user input to specify the city of interest.

The actual code in github repository includes some extra error checking and handling which weren’t included here for more readability. Furthermore, the application has also been integrated with WeatherUnderground API where it makes a REST call to that API and returns the weather for that city.


Screen Shot 2016-08-27 at 12.34.44 AM.png


Screen Shot 2016-08-27 at 12.35.35 AM.png

After making these edits, you can validate the results by running the code from the following joe4k/conversation-simple github repository.

  • Clone code from github repository

git clone

  • Create a new Conversation workspace by importing training/car_workspace_alchemy.json file
  • Obtain Alchemy Language API key
  • Obtain Weather Underground API key
  • Update the .env file with credentials for Conversation, Alchemy Language and Weather APIs

Run the application locally (npm start) and verify you get the following results:

Screen Shot 2016-08-27 at 12.37.36 AM.png


In conclusion, the Watson Conversation service offers a real intuitive and powerful interface for building bots and conversational agents. In this blog, we illustrated how we can extend Watson Conversation by extracting entities using Alchemy Language service to enrich the conversation based on that using context variables. While our example focused on extracting the City entity which comes readily available with Alchemy Language standard (pre-trained model), the same approach would work with any entities you’d extract using Alchemy Language custom models.

Data Considerations when Building a Cognitive Solution

As they embark on their cognitive journey, several teams struggle with what kinds of data are most adequate for cognitive solutions. In this blog, I will share some thoughts and suggestions to address the question of identifying data for cognitive solutions.

Kinds of Data:

The key ingredient for any cognitive solution is data. Specifically, two kinds of data are needed:

  • The knowledge base which is the corpus of documents that contain the information relevant to the use case
  • The ground truth which is the training data to teach the Machine Learning system how to identify and extract relevant knowledge/insights from the knowledge base (corpus).

For example, in a question/answer cognitive use case, it is critical that the answers to end-user questions reside somewhere in the knowledge base and it is as critical that the ground truth consists of representative end-user questions.

When considering what data to use for a cognitive use case, it is helpful to think of how you’d learn a new subject, for example, Economics. The typical learning process involves getting one or more books on the subject (Economics), which in this analogy, would constitute the knowledge base. Then to prepare for an exam on the subject, you’d go through several practice tests which are representative of the exam; these tests would map to the ground truth needed for training.

Data Format:

The other question to consider is data format. For this question, it is helpful to go back to the definition of cognitive systems as systems that learn and interact naturally with humans to help them extract knowledge and insight from big data. Humans commonly interact with one another using text, speech, and images. As such, IBM’s Watson Developer Cloud services are designed to handle text, speech, and images.

For instance, Alchemy Language, Natural Language Classifier, Conversation, Retrieve & Rank, Personality Insights and Tone Analyzer services mainly accept text as input.

Visual Recognition, on the other hand, accepts as input images, photographs, and drawings and returns as output insights to understand the contents of the image such as what objects are in the image, whether the images include a face or not and if so, is it the face of a male/female and what age group. Furthermore, Visual Recognition service can be trained to identify objects in an image based on custom classifiers designed for a particular task. For example, Visual Recognition can be used to differentiate sports cars from trucks and leopards from tigers.

For audio, Watson’s Speech to Text service accepts speech as input and produces text as output. Speech to text currently supports multiple languages (US English, UK English, Spanish, Japanese, Mandarin Chinese, Brazilian Portuguese, and Arabic) with a roadmap for supporting more languages in the future. Watson’s Speech to Text also has some unique capabilities as keyword spotting, profanity filtering, and word alternatives/confidence/timestamps.

Data Cleansing:

Teams planning on building cognitive solutions should include in their plans the effort and resources required for data cleansing. Data cleansing is a necessity because real data is rarely available without errors. The task of data cleansing involves detecting and removing errors and inconsistencies in data within one data source as well as across a variety of data sources. Common errors include misspelling, duplicate information, conflicting information, as well as formatting or invalid character encoding.

A variety of tools and techniques have been developed to help with the task of data cleansing including data analysis (sanity checking), defining data transformations (to match a specific schema), and identification and removal of duplicate and/or conflicting information. Data ingested into a cognitive system without being properly cleansed can lead to inaccuracies in retrieving results from the system.

Consider the example where 2 duplicate documents are ingested into the cognitive system. When training the cognitive system, a subject matter expert may select only one of the documents as containing the relevant information to a query. Such a scenario would lead to inaccuracy in the system as it thinks only one of the two duplicate documents are relevant which clearly is providing conflicting and inconsistent knowledge to train the system.


In conclusion, when starting on building a cognitive solution, teams need to plan for the effort and resources required to identify the relevant data for creating the knowledge base as well as the subject matter experts required to provide training data to the system. Understanding what data formats are support by the cognitive system you’re planning to leverage is also critical. Lastly, team needs to plan for data cleansing as it is a necessity for building successful cognitive applications.

Cognitive Solutions

Cognitive Solutions

Hi, my name is Joe Kozhaya and I am a Watson Solution Architect working closely with partners and clients to build cognitive solutions. In this blog, I’d like to share some thoughts and tips on best practices for cognitive solutions.