Building Blocks

In the first part of the series we have shown how to define intents and capture dialog attributes using AWS Lex and AWS Lamda functions ( We will dive now a little bit deeper into the mechanism we have used to be able to recommend some products based on the user answers.

There are multiple ways to implement product recommendations. I can refer to a previous post on that topic: For this experiment we will use a simple classifier that we will train with some artificially made examples.

The classifier is implemented using the Microsoft Azure Machine Learning studio. We will publish a trained model from the ML Studio through an API and call it from AWS. It is not the best and most efficient way, but this is fun to show the interaction of multiple cloud services.

Keeping the dialogue context

Finite state machine

Lots of virtual assistants are merely questions and answers systems. They do not keep the context and hence do not have the ability to follow a structured dialogue. Most of the assistants also can not branch between one topic and the other. The assistant asks the user to repeat same answers again and again.

A full dialog design is required to be able to jump from one topic to the other. Natural conversations do not follow a sequential path most of the time. A useful way to design a dialog is to use a transition state diagram or table for example. We discussed also in an earlier post . Designing properly the design and implementing it as a finite state machine becomes particularly key for complex dialog assistants. Users can therefore jump from topic to topic and the assistant has a definite state for each user action.

Implementing a finite state machine and keeping the context can be done in different ways in AWS lambda, but in our case we implemented with simple if-then statements, checking what is the intent of the user and depending on what he has already given as information, we can either proceed or ask for more.

Session attributes

AWS Lex provides a way to keep the context and pass it back and forth between the lambda function and the chatbot and the serverless function. No data is stored in the lambda by definition ( which is a great advantage to respect data privacy). You can read a full description here In our experiment, we keep a number of attributes.

In the below code extract, we can see that we are checking if the country of residence has been identified and in which case, we add it to the dictionary of session attribute with the key ‘countryOfResidence’.

Keeping session variables

Defining and publishing the classifier for product recommendation

Since we have no data we have defined a few training examples for our classifier, that we can use to bootstrap our model:

GenderMarital statusAge GroupAgeIncomeParenthoodEmployment LevelEmployer CategoryResidenceCountryProductNational
Sample training data

The training data is then fed into an Azure ML model using a multiclass random forest classifier

Once trained, the model is then exposed through a web service that can be called by our AWS Lamdba later on:

We can now integrate the web service call into our AWS lambda and fill up the API parameters with the dialog context as shown below:

We then get a list of possible products with their corresponding probabilities and chose the product with the highest probability to propose to the user:

Final result

The final result displayed in a test user interface looks like this

The probability that the product suits the potential client is 25%, thus already better than random. We have 15 products so a random pick would yield around 8% probability.

What is next

The current implementation of the model is not incremental and therefore needs to be retrained with new data to make it more accurate. Unfortunately that would mean storing the data in order to reuse for training. In order to circumvent that, we will show in the next article how to implement it using incremental ( also called online) learning.

(Visited 104 times, 1 visits today)
%d bloggers like this: