DiCE -ML models with counterfactual explanations for the sunk Titanic data-

Machine Learning Image

This article is an overview why counterfactual explanations are required in recent ML projects and how to apply Microsoft research DiCE library for Titatic data set.

There have been some foreseen and ongoing trends in AI/ML for 2020 such as AutoML, MLOps, AI ethic those are to democratize AI/ML in the industries more than ever. AutoML can automate deploying and optimizing a ML model as an orchestrating way in AI/ML lifecycle with MLOps. It reflects the one of IT aspects that abstracts a certain area into unconscious layer of the system and people won’t need to care about that underneath layer anymore once it’s embedded in the system.

For example, with the emergence of cloud services, people don’t need to care about the underlying network, server and storage to some extent. In the same way, with the spread of AI/ML in general, the word “AI” itself will be fading from the trend scene eventually. “AI”“IoT”“Blockchain” are current buzzwords apparently but the next decades these words would not be seen so frequentcy like we use and hear these days.

Another big trend is obviously “Explainable AI” (XAI) that referes to methods and techniques in the application of “AI”. The results of the solution can be understood and interpreted by human perceptions. While recent progressive techniques are deemed to generate “black box” models by deep learning (deep neural network), the relatively classical methods such as decision-tree, linear regression and some statistics are called “white-box” models, which give understandable reasons for influencing the result from given features in a model. Deep learning (deep neural network), boosting and random forest, highly non-linear regression generating models are not providing tranparent reasons for humans, which means people can not understand easily why that result is obtained from given model in an interpretable way.

Why has it been focused and been thought crucial for AI/ML recently? There might be two aspects, one which falls under ethical reason when some rules applied by a model seem to produce unfair and undesiable results for our ethical and moral thoughts, and the other one which falls under business reason that AI/ML should reveal why its regression or classifycation (or something as output) has resulted that particular answer.

These have been becoming more essential when AI adoptions spread widely through business and get embedded in our society everywhere. Let’s take a look at those aspects in detail.

Ethical reason— Unconscious bias caused by AI/ML

We’re usually unconscious about how “Black-box” models give results to us and how those have algorithmic bias and unfairness. Cambridge Analytica Scandal and Amazon scrapping its secret AI recruiting tool that showed bias against women are the famous incidents we have to recall here. It’s worse if we didn’t notice those bias and unfairness that had brought harmful disparity and inequalities among certain group of people. The latter Amazon case, it’s found that the system rated high score for men candidates in the hiring process with not so gender-neutral way because of the reflection of high men dominance in the tech industry at that time. From this angle, any system might look skeptical if they have such biases because the systems could devise other ways of evaluating people or things just by collected data automatically in AI/ML lifecycle. The fairlearn is the project for evaluations to assess your system’s fairness and mitigate the observed unfairness in the development of AI/ML. 

Business reason—Unknown reasons caused by AI/ML

Let’s think about a retirement prediction case (or a churn case). We’ve got a bunch of data about our employee and need to predict who will leave the company to prevent your company from letting your talented people go. Let’s think we generated a model from data and the model revealed that one of you engineers might leave the company soon, but wait why? OK maybe he will leave but what we need to know here is not what he will leave but why he will leave the company. The model can predict who will likely leave the company from given data easily, however the model doesn’t tell you what measures we can take to prevent him from leaving the company at a glance. To circumvent the possible consequence we would want to ask the model “What if” he had pay-raise within 2 years or “What if” his overtime work was less than 30 hours monthly, etc, etc.

Harnessing AI/ML models including “black-box” that are generated in such as Deep learning (deep neural network), boosting and random forest was thought to reduce reliance on subjective opinions by humans but here’s a different distinct hurdle that we have to overcome when we adopt such AIs. Those explainable and interpretable reasons have been invisible in “black-box” models outputs. In recent research and study, it’s now doable to obtain what conditions would have flipped model prediction with counterfactual explanations like “What if” hypothetical examples that we wanted to cast a question for the same input. We’ll go through one of the DiCE (Diverse Counterfactual Explanations) implementation as following to pursue counterfactual explanations for the ML models.

DiCE (Diverse Counterfactual Explanations)

Microsoft Research Ramaravind Kommiya MothilalAmit SharmaChenhao Tan published their recent study “Explaining Machine Learning Classifiers through Diverse Counterfactual Example” and DiCE implementation in github this January 2020. What is DiCE first of all? DiCE is one of the counterfactual explanations implementation by their research. This implementation is based on their recent research that generates diverse counterfactual explanations for any ML model.

DiCE implements counterfactual (CF) explanations that provide such information by showing feature-perturbed versions of the same case… In other words, it provides “what-if” explanations for model output and can be a useful complement to other explanation methods, both for end-users and model developers.

DiCE – github

Let’s delve into further more. DiCE is useful and a nice-to-have library with the implementation of counterfactual (CF) explanations that provides those “What if” cases by showing feature-perturbed versions of the same cases that would have had different predictions. This implementation also has come with feasibility of the counterfactual actions given user context and constraints, and diversities among the counterfactuals presented by tunable parameters to generate different kinds of explanations. There are some arguments we can give for feasibility and diversities in counterfactual explanations, which is nice.

There are 3 arguments of DiCE I’d like to cover in this article.

proximity and diversity weight

proximity_weight (default: 0.5) and diversity_weight (default: 1.0) are changeable values when we generate counterfactual examples (we will cover sample usage later). It’s a littel vague how far from default the value (0.5 and 1.0 respectively) should be configured for proximity and diversity. One idea is just to put an iteration variable for those arguments and use a loop to generate different sets of various counterfactual explanations how it varies.

# change proximity_weight from default value of 0.5 to 1.5
dice_exp = exp.generate_counterfactuals(query_instance, total_CFs=4, desired_class="opposite", proximity_weight=1.5, diversity_weight=1.0)


feature_weight is a dictionary argument we can give for each numerical features to configure its difficulty to change the feature value for counterfactual explanations. By default, DiCE computes the inverse of MAD internally and divides the distance between continuous features by the MAD of the feature’s values in the training set.

# assigning new weights
feature_weights = {'age': 10, 'hours_per_week': 5}
# Now generating explanations using the new feature weights
dice_exp = exp.generate_counterfactuals(query_instance,
                total_CFs=4, desired_class="opposite",

features_to_vary list

Some of the generated explanations suggest changes in features that cannot be varied easily (such as age), or sensitive attributes like race or gender. Hence, DiCE allows feeding in a list of features that are allowed to vary through the features_to_vary parameter. This listing can give only realistic set of counterfactual explanations for actionable alternative profiles for the same case.

# assign varying features as a list
dice_exp = exp.generate_counterfactuals(query_instance,
                total_CFs=4, desired_class="opposite",

How could Mrs survive from the sinking of the Titanic?

The Titanic accident happened in 1912. The RMS Titanicsank after colliding with an iceberg in the North Atlantic Ocean, four days into the ship’s maiden voyage from Southampton to New York City. Unfortunately, there weren’t enough lifeboats for everyone onboard, resulting in the death of 1502 out of estimated 2224 passengers and crew. Now it’s interesting in applying DiCE for this dataset “Titanic” train set and verify what sorts of people more likely were to survive from the sunk ship. We use only train.csv of dataset because it has the column survived.

You can sign up Kaggle to get train.csv data yourself, or search it on web.

Titanic: Machine Learning from Disaster

As you might already know, the survival rate for title Mr is relatively low compared to other titles such as Mrs and Miss. So my question here is what conditions could save one Mr. with “what if” hypothetical examples you consider especially if you we were a men (for example if you were the first row person Braud, Mr. Owen Harris who was 22 years-old man in pclass 3 with 1 sibling) See raw csv data in dataframe format below.

Under a typical feature engineering we can cope with the missing values and added the column “family_size” from siblings and parents information. After training a model with Keras we had to give our trained model to DiCE model object as below. Now we’re ready to do DiCEing with data object d and model object m for instantiating a DiCE class for generating counterfactual explanations.

Please note that you need to give backend argument for the type of model library, TensorFlow 1.x, TensorFlow 2.x or PyTorch respectively.

The variable backend below indicates the implementation type of DiCE we want to use. We use TensorFlow 1.x in the notebooks with backend=’TF1′. You can set backend to ‘TF2’ or ‘PYT’ to use DiCE with TensorFlow 2.x or with PyTorch respectively. We want to note that the time required to find counterfactuals with Tensorflow 2.x’s eager style of execution is significantly greater than that with TensorFlow 1.x’s graph execution.

DiCE getting started

It’s quite straightforward to initiate a DiCE instance and generate counterfactual samples. From this random result, the first and the second example remained male with the same age of the sample person “Braud, Mr. Owen Harris” himself. The third case was in paradox with the misleading of sex and title. It shows that if his title was Master or he had 8 siblings then he might have survived from sinking of the ship. Let’s not think changing the title or the number of siblings/parents for counterfactual set but look for more similar alternative profiles of him by using the features_to_vary argument now. Because the number of Master people’s sample was relatively low and having 8 siblings looked so extreme to consider those results as hypotheses.

I configured the proximity 1.5 from default value 0.5 and features_to_vary to only 4 features (pclass, age, fare, embarked). As a result counterfactual examples will have not changed sex, family thing and title. This optimization seems working fine to some extent. The third example shows that if he could pay more higher 14.01 (which is close to the pclass 2 median value) and the embarkation place was Cherbourg not from Southampton, he might have been saved. The rest three cases explains that a baby or child was potentially rescuee obviously under such circumstances.

Here’s the Jupyter notebook for all samples above for your reference.

DiCE -ML models with counterfactual explanations for the sunk Titanic data-

Leave a Reply

Your email address will not be published. Required fields are marked *