AutoML pipelines are a hot topic. The general goal is simple: enable everyone to train high-quality models specific to their business needs by relying on state-of-the-art machine learning models, hyper-tuning techniques and large volumes of compute.

In this blog post I will be applying Microsoft’s AutoML pipeline to a public ML competition, and by dissecting the results I hope to learn where AutoML pipelines add significant value and areas where they can still improve. With minor coding efforts and the AutoML pipeline, I was able to get to the 5th position with only 0.004 points from the top F1 score! You can find the notebook that I used on GitHub.

Richter’s Predictor: Modelling Earthquake Damage

The competition I picked is hosted at DrivenData.org. It is an intermediate-level practice competition, where the goal is to predict the level of damage to buildings caused by the 2015 Gorkha earthquake in Nepal.

The data is clean, without any missing values and mainly consists of information on the buildings’ structure and their legal ownership (both categorical and numerical features). In this competition, we are trying to predict the ordinal variable damage_grade, which represents a level of damage to the building that was hit by the earthquake. There are 3 grades of the damage.

The training and test dataset consists of respectively 260602 and 86869 buildings.

AutoML

AutoML is integrated into Microsoft’s Azure Machine Learning Service. This means it is relatively simple to execute and monitor AutoML pipelines using storage and compute in Azure.

The general workflow of an AutoML pipeline is fairly straightforward. You define the training dataset (the Richter dataset), a cross-validation scheme (5-fold cross validation), primary metric (weighted AUC), the experiment type (classification) and you are good to go. Depending on where you want to execute the experiment (on your local pc, a VM in the cloud or a large cluster) and where the data resides (local or in cloud), you also have to specify a data and compute configuration.

An AutoML pipeline consists of the following steps:
1. Given the experiment type, generate a set of initial pipeline parameters.
2. Execute the experiments with the different parameters and measure the primary metric using cross-validation.
3. Pick a new set of (optimal) pipeline parameters and continue until a threshold is reached. This can be a number of experiments, the time spent on the experiments or a different metric.
4. At the end, build an ensemble of the different models to obtain optimal performance on the test set.

Note that the general problem of selecting a good set of algorithms and hyperparameters is a complex problem. The search space (i.e. the model space) is very large and evaluating different experiments often takes a lot of compute and time. For quite a long time, hyper-tuning was done by performing either a random or full search of the model space. As compute is limited, this meant that these model spaces had to be heuristically constrained.

Nowadays, Bayesian methods are often seen as a superior approaches to hyperparameter optimization, although RL-based methods have also become quite popular in e.g. Neural Architecture Search. The general idea behind these methods is that they will ‘intelligently’ and ‘efficiently’ search the model space, trading off exploration (new model types) vs. exploitation (improving previously optimal model types).

Results

Directly applying the AutoML pipeline to the dataset results in a model that performs worse (F1 of 0.5441) than the competition baseline (a Random Forest model with F1 of 0.5815). Analysing the model results quickly illustrates why such a low F1 is achieved. The dataset is unbalanced (class 1: 7.5%, class 2: 52.5%, class 3: 40%). As the AutoML pipeline does not perform undersampling or oversampling, this means the different models in the AutoML pipeline are trained on unbalanced datasets.

The confusion matrix of the AutoML pipeline also confirms the bias towards the two majority classes that is present in the model. As the competition is evaluation on F1 micro score, this model doesn’t perform very well.

Although the AutoML does incorporate some feature engineering, preprocessing, missing value imputation, it is still important to provide a clean and balanced dataset to the AutoML pipeline.

To improve the results, I took the following steps:

1. Verify that the different features are converted to the correct format (numerical or categorical).
2. Perform synthetic data generation by leveraging SMOTE. This ensures that the data is balanced, without having to undersample or throw any of the data away.

The experiment was deployed on AzureML compute (managed VM’s) and 100 experiments were run with the AutoML pipeline.

As you can see in the plot below, running the pipeline for even more experiments wouldn’t have lead to a significant improvement in terms of performance, although this is most likely necessary to get to the 1st place in the competition.

Zooming in on the confusion matrix, it is clear that the model performs better, although there is still significant confusion between the second and the third class. Additional data augmentation techniques (e.g. undersampling or oversampling) or manual feature engineering might help in this scenario.

The following graph also showcases the importance of some of the features. Clearly, there are a lot of (sparse) features that have limited impact on final performance. As such, it is worthwhile to experiment with leaving out these features. Primarily the location features have the biggest impact, which is as expe

The final ‘best performing’ model achieves an F1 score of 0.7419. This is slightly lower than the best score in the competition, but considering the amount of work that was involved to get these results, I’d say this is a quite promising result for AutoML.

Conclusion

AutoML is a great addition to any data scientist’s toolbox. Hyperparameter tuning frameworks are not new (e.g. hyperopt), but a framework that easily allows data scientists to combine compute, data and experimentation in a single Python package is a great improvement. That said, in order to get the most out of these tools, it is necessary to perform the proper data preprocessing, to select the right optimization metric, etc. In addition, in order to avoid spending large amounts of compute and time on these workloads, it is possible to narrow down the search space based on data exploration and experience.

If you have any questions on AutoML, I’ll be happy to read them in the comments. Follow me on Medium or Twitter if you want to receive updates on my blog posts!

Achieving a top 5% position in an ML competition with AutoML was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most machine learning systems require the ability to explain to stakeholders why certain predictions are made. When choosing a suitable machine learning model, we often think in terms of the accuracy vs. interpretability trade-off:

• accurate and ‘black-box’:
  Black-box models such as neural networks, gradient boosting models or complicated ensembles often provide great accuracy. The inner workings of these models are harder to understand and they don’t provide an estimate of the importance of each feature on the model predictions, nor is it easy to understand how the different features interact.
• weaker and ‘white-box’:
  Simpler models such as linear regression and decision trees on the other hand provide less predictive capacity and are not always capable of modelling the inherent complexity of the dataset (i.e. feature interactions). They are however significantly easier to explain and interpret.

The accuracy vs. interpretability trade-off is based on a important assumption, namely that ‘explainability is an inherent property of the model’.
I strongly believe however that with the right ‘interpretability techniques’, any machine learning model can be made more interpretable, albeit at a complexity and cost which is higher for some models than others.

In this blog post, I will discuss some of the different techniques that can be used to interpret machine learning models. The structure and content of this blog post is highly based on the H20.ai booklet on Machine Learning Interpretability. I highly recommend everyone to read the H20.ai booklet or other material by Patrick Hall if you want to learn more!

Model properties

The degree of explainability of a model is often linked to two properties of the response function. The response function f(x) of a model defines the input-output relationship between a the input (features x) and the output (target f(x)) of a model. Depending on the machine learning model, this function has the following traits:

• Linearity: In a linear response function, the association between a feature and the target behaves linearly. If a feature changes linearly, we also expect the target to change linearly at a similar rate.
• Monotonicity: In a monotonic response function, the relationship between a feature and the target is always in one direction (increase or decrease) over the feature. More importantly, this relationship holds over the entire feature domain and is independent of the other feature variables.

Examples of linear and monotonic functions are e.g. linear regression models, whereas e.g. random forests and neural networks are examples of models that exhibit highly non-linear and non-monotonic response functions.

The following slide by Patrick Hall illustrates why white-box models (with linear and monotonic functions) are often preferred when clear and simple model explanations are required. The top plot shows that the number of purchases increases when the age increases. The response function has a linear and monotonic relationship at a global level, readily interpretable by all stakeholders.

A significant portion of the trend is however missed due to the linear and monotonic constraints of the white-box model. By exploring more complex machine learning models, it is possible to better fit the observed data, although the response function is only linear and monotonic at a local level. In order to interpret the models behaviour, it is necessary to investigate the model at a local level.

The scope of model interpretability, i.e. at a global or local level, is inherently linked to the complexity of the model. Linear models exhibit the same behaviour across the entire feature space (as seen in the top plot) and they are thus globally interpretable. The relationship between the input and output is often limited in complexity and local interpretations (i.e. why does a model make a certain prediction at a certain data point?) default to global interpretations.

For more complex models, the global behaviour of the model is harder to define and local interpretations of small regions of the response functions are required. These small regions are more likely to behave linear and monotonic, enabling a more accurate class of explanations.

In the remainder of this blog post, I will focus on two model-agnostic techniques that provide both global and local explanations. These techniques can be applied to any machine learning algorithm and they enable interpretability by analysing the response function of the machine learning model.

Interpretability techniques

Surrogate models

Surrogate models are (generally simpler) models that are used to explain a more complex model. Linear models and decision tree models are often used because of their simple interpretation. The surrogate model is created to represent the decision making process of the complex model (the response function) and is a model trained on the input and model predictions, rather than input and targets.
Surrogate models provide a layer of global interpretability on top of non-linear and non-monotonic models, but they should not be relied on exclusively. Surrogate models are not able to perfectly represent the underlying response function, nor are they capable of capturing the complex feature relationships. They serve primarily as ‘global summary’ of a model. The following steps illustrate how you can build a surrogate model for any black-box model.

1. Train a black-box model.
2. Evaluate the black box model on the dataset.
3. Choose an interpretable surrogate model (typically a linear model or a decision tree).
4. Train the interpretable model on the dataset and its predictions.
5. Determine the surrogate model error measure and interpret the surrogate model.

LIME

The general idea behind LIME is the same as surrogate models. LIME however does not build a global surrogate model that represents the entire dataset and only builds local surrogate models (linear models) that explain the predictions at local regions. A more in-depth explanation of LIME can be found at this blog post on LIME.
LIME provides an intuitive way to interpret model predictions for a given data point.

The following steps illustrate how you can build a LIME model for any black-box model.

1. Train a black-box model.
2. Sample points of the local region of interest. Points can be retrieved from the dataset, or artificial points can be generated.
3. Weight the new samples by their proximity to the region of interest. Fit a weighted, interpretable (surrogate) model on the dataset with the variations.
4. Interpret the local surrogate model.

Conclusion

There are several different techniques that you can use to improve the interpretability of your machine learning models. Although the techniques are becoming more robust as the field improves, it is important to always compare different techniques. A technique I didn’t discuss are Shapley Values. Have a look at Christoph Molnar’s book on ‘Interpretable Machine Learning’ to learn more about that (and other) techniques!

If you have any questions on interpretability in machine learning, I’ll be happy to read them in the comments. Follow me on Medium or Twitter if you want to receive updates on my blog posts!

Machine learning interpretability techniques was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

The past year, I have been working as a Data Scientist at Microsoft, solving problems of enterprise customers. The experience I gained from working across industries tested my skills in a wide variety of ways, both from a data science perspective and from a problem solving perspective. A large portion of the time is typically spent defining the problem, creating a dataset and cleaning the data and large datasets are almost always harder to come by.

In this blog post I share some of the lessons learned and pitfalls you might experience when working on data science projects ‘in the wild’. A lot of these pitfalls are almost always present, and it is often necessary to be ‘creative’ in order to solve them.

Pitfalls

Descriptive, predictive and prescriptive analytics

There are several different ways data can be leveraged to improve business processes. The assignment you typically get from a customer is to ‘solve business problem X’. A concrete example is e.g. ‘improve the profitability of the marketing campaigns’.

A common pitfall is not tackling problems in the ‘right’ order. If you want to improve a process, you need to properly understand it, before even thinking of automating parts of it. Customers typically have limited knowledge on their own data and no experience with data science. It is thus very important to clearly explain to them what the different options are from a data science perspective.

Often, you start the project by cleaning and analyzing the data. The terms ‘descriptive and diagnostic’ analytics are used when you aim to build summaries of the data and try understand how the different variables in the data relate. You build visualizations and use (unsupervised) machine learning techniques to cluster data points or find correlated variables. Based on the outcome of the process, you can e.g. build a report or dashboard, which lists and investigates a set of KPI’s that are useful for the business problem. With marketing campaigns, you could correlate sales and marketing data in order to understand why campaigns are successful. The conclusions (e.g. a lower price results in more sales) might not always be ‘rocket science’, but they allow the customer to validate their hypothesis using their data. In addition, it also allows them to spot anomalous behavior and whether they have the right type of data.

Predictive and prescriptive analytics are about predicting the future and taking actions based on these predictions. With predictive analytics you take the historical data, and build a machine learning model to predict future data points (within a certain error range). In marketing, novel campaign ideas are often validated by estimating the expected sales using a predictive model. By having done the previous descriptive and diagnostic phase, you should have a clear idea of what you can expect in terms of performance. If the data quality is not good enough to build a robust model, this can be flagged to the customer and you can backup your claims using the data they provided.

With prescriptive analytics, the goal is to take actions based on predictions, and optimize certain aspects of the proces. Instead of validating campaign ideas, you could e.g. build an optimisation engine that can generate the list of ‘best future campaigns’. Building this system requires large amounts of high quality data. Note that data science is all about underpromising and over delivering, so start small and build big!

Proof of Concepts vs. pilots

Customers often like to work with a Proof of Concept in order to investigate what is possible with ‘data science’. Typically, this means that they provide a subset of the data, and they want to determine some preliminary results. Although a customer typically understands you won’t get good performance on with the PoC, it is still a common request. The downside however of a PoC is that a subset of the data is often not representative of the full dataset and problem. You might get extremely good performance out of the PoC, but you might be unable to replicate this on the full dataset. Customers select the dataset by e.g. looking at only a small time segment, which could heavily bias the PoC model.

A better option, if the customer wants to experiment, is to work with pilots. In pilots, you work with the full dataset, and you run through an initial iteration of the data science pipeline (data cleaning, modeling, etc). Working with the full dataset mitigates a lot of risk in the project. The model performance will still not be optimal, as you only got limited time, but at least you should have been able to get a representative picture.

Representative datasets

Although this pitfall is similar to the previous one, it is not the same. Especially if you work with unstructured data (e.g. images, text data, etc), a customer might have already collected data before you start the project. A critical, but often overlooked element of the dataset is whether it is representative of the use case. If datasets need to be collected, it should be done in the same fashion as the model will ultimately be used.

For example, if you want to do inventory management using computer vision, it is important to have images of objects in the store or the fridge, where the model will be used. Catalogue type images will not result in a robust model, as they don’t represent the use case. The model must learn robust features in order to detect the object in the environment.

High performance and overfitting

The golden rule of data science is to be suspicious when you get extremely good performance (>90%) at the start of the problem.
Good performance at the start of the project could be an indicator of ‘leaky’ variables or a ‘leaky’ dataset. Leaky variables are variables that are highly correlated with the target variable, and that are unlikely to be available at inference time. If the goal is to predict sales, you are not able to use the sales of other products as features because this data won’t be available.
A ‘leaky’ dataset happens when the dataset only reflects a certain (time) segment. The problem that needs solving is typically significantly easier, and it is quite likely that the model would fit towards noise in the data, instead of the actual signal.

A model with high performance is great, but only if it performs equally well on a completely new and random dataset!

Interpreting correlation as causation

I highly enjoyed this blog post on statistical fallacies. Interpreting correlation as causation is only one of the type of errors that is often made, and getting a strong understanding of the statistics behind them is key.

Interpretability of models and data

If a customer uses the model as a basis for actions, they will always prefer solutions that are interpretable and understandable. In this blog post I went in-depth into the reasons why model interpretability is key. I also provided a more-in depth look at the different techniques that you can use.

Conclusion

I only touched on 6 potential data science pit falls, but I am convinced that I probably made significantly more errors in the past year. If you have any experience on data science projects, and want to share your commonly encountered problems, I’ll be happy to read them in the comments. Follow me on Medium or Twitter if you want to receive updates on my blog posts!

Common data science pitfalls and how to avoid them was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why is it necessary to understand interpretability methods?

If you trust a technique with explaining the predictions of your model, it is important to understand the underlying mechanics of that technique, and any potential pitfalls associated with it. Interpretability techniques are not fault proof, and without a good understanding of the method, you are very likely to base your assumptions on falsehoods.

A similar but significantly more thorough investigation was done in the following blog post on random forest importance’s. Feature importance is often used to determine which features play an important role in the model predictions. Random forests provide an out-of-the-box method to determine the most important features in the dataset and a lot of people rely on these feature importance's, interpreting them as a ‘ground truth explanation’ of the dataset.

The authors investigated two random Forest (RF) implementations and the standard measures of feature importance they provide. The authors show that permutation importance provides more robust estimates when variables are strongly correlated, compared to random forest importance’s. I highly recommend to read their blog post for a thorough understanding of the findings.

LIME

LIME is model-agnostic, meaning that it can be applied to any machine learning model. The technique attempts to understand the model by perturbing the input of data samples and understanding how the predictions change.

Model-specific approaches aim to understand the black model machine learning model by analysing the internal components and how they interact. In deep learning models, it is e.g. possible to investigate activation units and to link internal activations back to the input. This requires a thorough understanding of the network and doesn’t scale to other models.

LIME provides local model interpretability. LIME modifies a single data sample by tweaking the feature values and observes the resulting impact on the output. Often, this is also related to what humans are interested in when observing the output of a model. The most common question is probably: why was this prediction made or which variables caused the prediction?

Other model interpretability techniques only answer the question above from the perspective of the entire dataset. Feature importance’s explain on a dataset level which features are important. It allows you to verify hypotheses and whether the model is overfitting to noise, but it is hard to diagnose specific model predictions.

Intuition behind LIME

A key requirement for LIME is to work with an interpretable representation of the input, that is understandable to humans. Examples of interpretable representations are e.g. a BoW vector for NLP, or an image for computer vision. Dense embeddings on the other hand or not interpretable, and applying LIME probably won’t improve interpretability.

The output of LIME is a list of explanations, reflecting the contribution of each feature to the prediction of a data sample. This provides local interpretability, and it also allows to determine which feature changes will have most impact on the prediction.

An explanation is created by approximating the underlying model locally by an interpretable one. Interpretable models are e.g. linear models with strong regularisation, decision tree’s, etc. The interpretable models are trained on small perturbations of the original instance and should only provide a good local approximation. The ‘dataset’ is created by e.g. adding noise to continuous features, removing words or hiding parts of the image. By only approximating the black-box locally (in the neighborhood of the data sample) the task is significantly simplified.

Potential pitfalls

Although the general idea of LIME sounds easy, there are a couple of potential drawbacks.

In the current implementation, only linear models are used to approximate local behaviour. To a certain extent, this assumption is correct when looking at a very small region around the data sample. By expanding this region however, it is possible that a linear model might not be powerful enough to explain the behavior of the original model. Non-linearity at local regions happens for those datasets that require complex, non-interpretable models. Not being able to apply LIME in these scenario’s is a significant pitfall.

Secondly, the type of modifications that need to be performed on the data to get proper explanations are typically use case specific. The authors gave the following example in their paper:
For example, a model that predicts sepia-toned images to be retro cannot be explained by presence or absence of super pixels.

Often, simple perturbations are not enough. Ideally, the perturbations would be driven by the variation that is observed in the dataset. Manually steering the perturbations on the other is probably not a great idea, as it most likely would introduce bias into the model explanations.

Conclusion

LIME is a great tool to explain what machine learning classifiers (or models) are doing. It is model-agnostic, leverages simple and understandable idea’s and does not require a lot of effort to run. As always, even when using LIME, it is still important to correctly interpret the output.

If you have any questions on interpretability in machine learning, I’ll be happy to read them in the comments. Follow me on Medium or Twitter if you want to receive updates on my blog posts!

Understanding model predictions with LIME was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

Similar to the blogpost I wrote on the different image classification architectures, I will go over two object detection architectures. I will discuss SSD and Faster RCNN, which are currently both available in the Tensorflow Detection API.

First I will go over some key concepts in object detection, followed by an illustration of how these are implemented in SSD and Faster RCNN.

Image classification vs. object detection

People often confuse image classification and object detection scenarios. In general, if you want to classify an image into a certain category, you use image classification. On the other hand, if you aim to identify the location of objects in an image, and e.g. count the number of instances of an object, you can use object detection.

There is however some overlap between these two scenarios. If you want to classify an image into a certain category, it could happen that the object or the characteristics that are required to perform categorisation are too small with respect to the full image. In that case, you would achieve better performance with object detection instead of image classification even if you are not interested in the exact location or counts of the object.

Imagine you need to check circuit boards and classify them as either defect or correct. While it is essentially a classification problem, the defects might be too small to be noticeable with an image classification model. Constructing an object detection dataset will cost more time, yet it will result most likely in a better model.

With an image classification model, you generate image features (through traditional or deep learning methods) of the full image. These features are aggregates of the image. With object detection, you do this on a more fine-grained, granular, regional level of the image. In the former you might lose track of the classification signal, whereas in the latter the signal might be preserved in a way that is more suitable for the use case.

Data requirements

In order to train a custom model, you need labelled data. Labelled data in the context of object detection are images with corresponding bounding box coordinates and labels, i.e. the bottom left and top right (x,y) coordinates + the class .

A question that is always asked is the following: in order to do object detection on problem X, how many pictures do I need? Instead, it is more important to properly understand in which scenarios the model will be deployed. It is crucial that a large number (e.g. > 100 and potentially >1000) representative images are available per class. Representative in this context means that they should corresponds with the range of scenarios in which the model will be used. If you are building a traffic sign detection model that will run in a car, you have to use images taken under different weather, lighting and camera conditions in their appropriate context. Object detection models are not magic and actually rather dumb. If the model does not have enough data to learn general patterns, it won’t perform well in production.

General object detection framework

Typically, there are three steps in an object detection framework.
1. First, a model or algorithm is used to generate regions of interest or region proposals. These region proposals are a large set of bounding boxes spanning the full image (i.e. an object localisation component).
2. In the second step, visual features are extracted for each of the bounding boxes, they are evaluated and it is determined whether and which objects are present in the proposals based on visual features (i.e. an object classification component).
3. In the final post-processing step, overlapping boxes are combined into a single bounding box (i.e. non maximum suppression).

Region proposals

Several different approaches exist to generate region proposals. Originally, the ‘selective search’ algorithm was used to generate object proposals. Lillie Weng provides a thorough explanation on this algorithm in her blog post. In short, selective search is a clustering based approach which attempts to group pixels and generate proposals based on the generated clusters.

Other approaches use more complex visual features extracted from the image to generate regions (e.g. based on the features from a deep learning model) or adopt a brute-force approach to region generation. These brute-force approaches are similar to a sliding window that is applied to the image, over several ratios and scales. These regions are generated automatically, without taking into account the image features.

An important trade-off that is made with region proposal generation is the number of regions vs. the computational complexity. The more regions you generate, the more likely you will be able to find the object. On the flip-side, if you exhaustively generate all possible proposals, it won’t be possible to run the object detector in e.g. real-time. In some cases, it is possible to use problem specific information to reduce the number of ROI’s (e.g. pedestrian typically have a ratio of approximately 1.5, so it is not useful to generate ROI’s with a ratio of 0.25).

Feature extraction

The goal of feature extraction is to reduce a variable sized image to a fixed set of visual features. Image classification models are typically constructed using strong visual feature extraction methods. Whether they are based on traditional computer vision approaches (e.g. filter based approached, histogram methods, etc.) or deep learning methods, they all have the exact same objective: extract features from the input image that are representative for the task at hands and use these features to determine the class of the image. In object detection frameworks, people typically use pretrained image classification models to extract visual features, as these tend to generalise fairly well (e.g. a model trained on the MS CoCo dataset is able to extract fairly generic features). In order to improve the model however, it is advised to experiment with different approaches. My blog post on transfer learning provides a clear distinction between the different types of transfer learning as well as their advantages and disadvantages (general and applications).

Non-maximum suppression

The general idea of non-maximum suppression is to reduce the number of detections in a frame to the actual number of objects present. If the object in the frame is fairly large and more than 2000 object proposals have been generated, it is quite likely that some of these will have significant overlap with each other and the object. Watch this video on Coursera to learn more about NMS. NMS techniques are typically standard across the different detection frameworks, but it is an important step that might require hyperparameter tweaking based on the scenario.

Evaluation metric

The most common evaluation metric that is used in object recognition tasks is ‘mAP’, which stands for ‘mean average precision’. It is a number from 0 to 100 and higher values are typically better, but it’s value is different from the accuracy metric in classification.

Each bounding box will have a score associated (likelihood of the box containing an object). Based on the predictions a precision-recall curve (PR curve) is computed for each class by varying the score threshold. The average precision (AP) is the area under the PR curve. First the AP is computed for each class, and then averaged over the different classes. The end result is the mAP.

Note that a detection is a true positive if it has an ‘intersection over union’ (IoU or overlap) with the ground-truth box greater than some threshold (usually 0.5). Instead of using mAP we typically use mAP@0.5 or mAP@0.25 to refer to the IoU that was used.

Tensorflow Detection API

The Tensorflow Detection API brings together a lot of the aforementioned ideas together in a single package, allowing you to quickly iterate over different configurations using the Tensorflow backend. With the API, you are defining the object detection model using configuration files, and the Tensorflow Detection API is responsible for structuring all the necessary elements together.

Protos

In order to have a better understanding of what the different supported components are, have a look at the ‘protos folder’ which contains the function definitions. Especially, the train, eval, ssd, faster_rcnn and preprocessing protos are important when fine-tuning a model.

SSD (Single Shot Multibox Detector)

Overview
The SSD architecture was published in 2016 by researchers from Google. It presents an object detection model using a single deep neural network combining regional proposals and feature extraction.

A set of default boxes over different aspect ratios and scales is used and applied to the feature maps. As these feature maps are computed by passing an image through an image classification network, the feature extraction for the bounding boxes can be extracted in a single step. Scores are generated for each object category in every of the default bounding boxes. In order to better fit the ground truth boxes adjustment offsets are calculated for each box.

Different feature maps in the convolutional network correspond with different receptive fields and are used to naturally handle objects at different scales . As all the computation is encapsulated in a single network and fairly high computational speeds are achieved (e.g. for 300 × 300 input 59 FPS).

Usage
For the usage we will investigate the different sample configuration files for SSD. Several parameters are important when leveraging the SSD architecture and we will go over them one by one.

First, different classification networks have different strengths and weaknesses (see this blog post for an overview). The Inceptionv3 network for example is trained to detect objects well at different scales, whereas the ResNet architecture achieves very high accuracy overall. Mobilenet on the other is a network that was trained to minimise the required computational resources. The performance of the feature extraction network on ImageNet, the number of parameters and the original dataset it was trained on are a good proxy for the performance/speed tradeoff. The feature extractor is defined in the ‘feature_extractor’ section.

A second obvious set of parameters are the settings for the default boxes and aspect ratios. Depending on the type of problem, it is worthwhile to analyse the various aspect ratios and scales of the bounding boxes of the labeled data. Setting the aspect ratios and scales will ensure that the network does not do unnecessary calculations. You can tweak these in the ‘ssd_anchor_generator’ section. Note that adding more scales and aspect ratios will lead to better performance, but typically with diminishing returns.

Thirdly, when training the model it is important to set the image size and data augmentation options in the ‘data_augmentation_options’ and ‘image_resizer’ sections. A larger image size will perform better as small object are often hard to detect, but it will have a significant computational cost. Data augmentation is especially important in the context of SSD in order to be able to detect objects at different scales (even at scales which might not be present in the training data).

Finally, tweaking the ‘train_config’, setting the learning rates and batch sizes is important to reduce overfitting, and will highly depend on the size of the dataset you have.

Faster R-CNN

Overview
Faster R-CNN was developed by researchers at Microsoft. It is based on R-CNN which used a multi-phased approach to object detection. R-CNN used Selective search to determine region proposals, pushed these through a classification network and then used an SVM to classify the different regions.

Faster R-CNN, similar to SSD, is an end-to-end approach. Instead of using default bounding boxes, Faster R-CNN has a Region Proposal Network (RPN) to generate a fixed set of regions. The RPN uses the convolutional features from the the image classification network, enabling nearly cost-free region proposals. The RPN is implemented as a fully convolutional network that predicts object bounds and objectness scores at each position.

Note that the RPN has a similar setup as the the SSD network (i.e. it does not predict bounding boxes out of thin air). The RPN network works with sliding windows across the feature maps. At each sliding-window location or anchor, a set of proposals are computed with various scales and aspect ratios. Similar to SSD, the outcome of the RPN are ‘adjusted’ bounding boxes, based on the anchors.

The different components are combined in a single setup and are trained either end-to-end or in multiple phases (to improve stability). Another interpretation of the RPN is that it guides the networks ‘attention’ to interesting regions.

Usage
Most of the usage details of Faster R-CNN are similar as the ones for SSD. In terms of raw mAP, Faster R-CNN typically outperforms SSD, but it requires significantly more computational power.

An important section for the Fast-RCNN detector, is the ‘first_stage_anchor_generator’ which defines the anchors generated by the RPN. The strides in this section defines the steps of the sliding window. Note that especially when attempting to detect small objects (if the stride is too large, you might miss them).

Although no extensive data augmentation was used by the authors of the Faster-RCNN paper, it is still advised to use it when working with smaller datasets.

Conclusion

There are several more object detection architectures, which I haven’t touched upon. Especially when looking at real-time applications, Yolov2 is often coined as an important architecture (fairly similar to SSD). I will update this blog post whenever it is added to the Tensorflow Detection API.

Questions

If you have any questions, I’ll be happy to read them in the comments. Follow me on Medium or Twitter if you want to receive updates on my blog posts!

Going deep into object detection was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

Key concepts

Although different researchers in the computer vision field tend to follow different practices, overall you can see the following trends when setting up experiments. I discuss how the images are pre-processed, what type of data augmentation is used, the optimisation mechanism and the implementation of the final layer.

Pre-processing
Often, the mean pixel value is computed over the training set and subtracted from the images. Note that it is important to take this into account when using these models with keras. Keras provides different ‘pre-processing’ functions for each of the computer vision models.

Data augmentation
Image classification research datasets are typically very large. Nevertheless, data augmentation is often used in order to improve generalisation properties. Typically, random cropping of rescaled images together with random horizontal flipping and random RGB colour and brightness shifts are used. Different schemes exist for rescaling and cropping the images (i.e. single scale vs. multi scale training). Multi-crop evaluation during test time is also often used, although computationally more expensive and with limited performance improvement. Note that the goal of the random rescaling and cropping is to learn the important features of each object at different scales and positions. Keras does not implement all of these data augmentation techniques out of the box, but they can easily implemented through the preprocessing function of the ImageDataGenerator modules. The data augmentation techniques by Andrew Howard explain the key methods more in-depth.

Training mechanism
Models are typically trained with a batch size of 256, using multi-GPU data parallelism, which is also available in keras. Either SGD with momentum or RMSProp is often used as optimisation technique. Learning rate schemes are often fairly simple, either lowering the learning rate when the validation loss or accuracy starts to stabilise or lowering the learning rate at a fixed interval. With the ‘ReduceLROnPlateau’ callback in keras, you can easily mimick this behaviour.

Final layer
The final layer in an image classification network was traditionally a fully connected layer. These layers are massive parameters hogs as you need NxM parameters to go from N to M hidden layer nodes. Nowadays, these layers have been replaced by average or max pooling layers requiring less parameters and computational time. When fine-tuning pre-trained networks in keras, it is important to take this into account to limit the number of parameters that are added.

VGGNet

Originally published in 2014 by Karen Simonyan and Andrew Zisserman, VGGNet showed that stacking multiple layers is a critical component for good performance in computer vision. Their published networks contain 16 or 19 layers and consist primarily of small 3x3 convolutions and 2x2 pooling operations.

The authors main contribution is showing that stacking multiple small filters without pooling can increase the representational depth of the networks while limiting the number of parameters. By stacking e.g. three 3×3 conv. layers instead of using a single 7×7 layer several limitations are overcome. First, three non-linear functions are combined instead of a single one, which makes the decision function more discriminative and expressive. Second, the number of parameters is reduced by 81% while the receptive field stays the same. Working with smaller filters thus also acts as a regularizer and improves the effectiveness of the different convolutional filters.

A downside of the VGGNet is that it is more expensive to evaluate than shallow networks and uses a lot more memory and parameters (140M). A lot of these parameters can be attributed to the first fully connected layer. It was shown that these layers can be removed with no performance downgrade while significantly reducing the number of necessary parameters. VGG is available on keras with pre-trained weights, both in the 16 and 19 layers variant.

ResNet

The ResNet architecture was developed by Kaiming He et al. in an attempt to train networks with even larger depth. The authors noted that increasing the network depth resulted in a higher training loss, indicating potential training convergence issues due to gradient problems (exploding/vanishing gradients).

Their main contribution is the addition of skip connections to neural network architectures, using batch normalisation and removing the fully connected layers at the end of the network.

Skip connections are based on the idea that as long as a neural network model is able to ‘properly’ propagate the information from the previous layers to the next layer, it should be able to become ‘indefinitely’ deep. In case no additional information is aggregated by going deeper, than a convolutional layer with a skip connection can act as the identity function.
By adding skip connections to the network the default function of a convolutional layer becomes the identify function. Any new information that the filters learn, can be subtracted or added to the base representation and it is thus easier to optimize the residual mapping. Skip connections do not increase the number of parameters, but do result in more stable training and a significant performance boost because deeper networks can be attained(e.g. networks of depth 34, 50, 101 and 152). Note that 1x1 convolutions are used to map a layers input to its output!

In addition to the skip-connections, batch normalisation was used after each convolution and before each activation. Finally, fully-connected layers were removed and instead an average pooling layer was used to reduce the number of parameters. The increased abstraction power of the convolutional layers due to a deeper network reduces the need for fully connected layers.

GoogLeNet

The GoogLeNet paper was published around the same time as the ResNet paper but introduces different improvements. The previous two papers focused on increasing the representation depth of classification network.
With GoogLeNet however, the authors still attempt to scale up networks (up to 22 layers) but at the same time they aim to reduce the number of parameters and required computational power. The original Inception architecture was published by Google and focused on applying CNN’s in big-data scenario’s as well as mobile settings. The architecture is fully convolutional and consists of Inception modules. The goal of these modules is to increase the convolutional filters learning abilities and abstraction power by constructing a complex filter which consists of multiple building blocks (e.g. a network in network — Inception).

In addition to Inception modules, the authors also used auxiliary classifiers to promote more stable and better convergence. The idea of auxiliary classifiers is that several different image representations are used to perform classification (yellow boxes). As a result, gradients are calculated at different layers in the model, which can then be used to optimise training.

Inceptionv3

With the Inceptionv3 architecture a couple of innovations are combined.
In Inceptionv3, the primary focus is on reusing some of the original ideas GoogLeNet and VGGNet, i.e. using the Inception module and expressing large filters more efficiently with a series of smaller convolutions. In addition to small convolutions, the authors also experiment with assymmetric convolutions (e.g. replacing nxn by nx1 and 1xn instead of multiple 2x2 and 3x3 filters).

The authors improved regularisation of the network by performing batch-normalisation and label-smoothing. Label-smoothing is the practice of assigning each class some weight, instead of assigning the ground truth label the full weight. As the network will overfit less on the training labels, it should be able to generalise better, which is is a similar practice as using L2 regularisation.

A lot of care was put into ensuring that the model would perform well on both high and low resolution images, which is enabled by the Inception modules analysing the image representations at different scales. As a result, when Inception networks are used in object detection framework, they perform well as classifying small and low resolution objects.

NASNet

The last image classification architecture I will discuss is NASNet, which was constructed using the Neural Architecture Search (NAS) framework. The goal of NAS is to use a data-driven and intelligent approach to constructing the network architecture instead of intuition and experiments. Although I won’t go into details of the framework, the general idea is explained.
In the Inception paper, it was shown that a complex combination of filters in a ‘cell’ can significantly improve results. The NAS framework defines the construction of such a cell as an optimisation process, and then stacks the multiple copies of the best cell to construct a large network.

Ultimately, two different cells are constructed and used to train the full model.

Results

The table below was taken from Keras and it provides a good overview of the results of the different networks I discussed. Note that the VGG stand out with their massive number of parameters, whereas Resnet50 and Inceptionv3 stand out with their impressive network depth. At the moment of writing, NASnet (not in table) achieves best performance with 82.7% top-1 and 96.2% top-5 accuracy on ImageNet.

Questions

If you have any questions, I’ll be happy to read them in the comments. Follow me on Medium or Twitter if you want to receive updates on my blog posts!

Going deep into image classification was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why is interpretability in machine learning important?

In traditional statistics, we construct and verify hypotheses by investigating the data at large. We build models to construct rules that we can incorporate into our mental models of processes. A marketing firm for example can build a model that correlates marketing campaign data to finance data in order to determine what constitutes an effective marketing campaign.
This is a top-down approach to data science, and interpretability is key as it is a cornerstone of the rules and processes that are defined. As correlation often does not equal causality, a solid model understanding is needed when it comes to making decisions and explaining them.

In a bottom-up approach to data science, we delegate parts of the business process to machine learning models. In addition, completely new business ideas are enabled by machine learning . Bottom-up data science typically corresponds to the automation of manual and laborious tasks. A manufacturing firm can for example put sensors on their machines and perform predictive maintenance. As a result, maintenance engineers can work more efficiently and don’t need to perform expensive periodic checks. Model interpretability is necessary to verify the that what the model is doing is in line with what you expect and it allows to create trust with the users and ease the transition from manual to automated processes.

As a data scientist you are often concerned with fine-tuning models to obtain optimal performance. Data science is often framed as: ‘given data X with labels y, find the model with minimal error’. While the ability to train performant models is a critical skill for a data scientist, it is important to be able to look at the bigger picture. Interpretability of data and machine learning models is one of those aspects that is critical in the practical ‘usefulness’ of a data science pipeline and it ensures that the model is aligned with the problem you want to solve. Although it is easy to lose yourself in experimenting with state-of-the-art techniques when building models, being able to properly interpret your findings is an essential part of the data science process.

Why is it essential to do an in-depth analysis of your models?

There are several reasons to focus on model interpretability as a data scientist. Although there is overlap between these, they capture the different motivations for interpretability:

Identify and mitigate bias.

Bias is potentially present in any dataset and it is up to the data scientist to identify and attempt to fix it. Datasets can be limited in size and they might not be representable for the full population, or the data capturing process might have not accounted for potential biases. Biases often only become apparent after thorough data analysis or when the relation between model predictions and the model input is analysed. If you want to learn more about the different types of types of bias exist, I highly recommend the video below. Note that there is no single solution to resolving bias, but a critical step towards interpretability being aware of potential bias.

Other examples of bias are the following:

e.g. word2vec vectors contain gender biases due to the inherent biases that are present in the corpora they have been trained on. When you would train a model with these word embeddings, a recruiter searching for "technical profiles" will leave female resumes at the bottom of the pile.

e.g. when you train an object detection model on a small, manually created dataset, it is often the case that the breadth of images is too limited. A wide variety of images of the objects in different environments, different lightning conditions and different angles is required in order to avoid an model that only fits to noisy and unimportant elements in the data.

Accounting for the context of the problem.

In most problems, you are working with a dataset that is only a rough representation of the problem you are trying to solve and a machine learning model can typically not capture the full complexity of the real-life task. An interpretable model helps you to understand and account for the factors that are (not) included in the model and account for the context of the problem when taking actions based on model predictions.

Improving generalisation and performance.

A high interpretability typically leads to a model that generalises better. Interpretability is not about understanding every single detail of the model for all of the data points. The combination of solid data, model and problem understanding is necessary to have a solution that performs better.

Ethical and legal reasons.

In industries like finance and healthcare it is essential to audit the decision process and ensure it is e.g. not discriminatory or violating any laws. With the rise of data and privacy protection regulation like GDPR, interpretability becomes even more essential. In addition, in medical applications or self-driving cars, a single incorrect prediction can have a significant impact and being able to ‘verify’ the model is critical. Therefore the system should be able to explain how it reached a given recommendation.

Interpreting your models

A common quote on model interpretability is that with an increase in model complexity, model interpretability goes down at least as fast. Feature importance is a basic (and often free) approach to interpreting your model. Even for black-box models such as deep learning, techniques exist to improve interpretability. Finally, the LIME framework will be discussed, which serves as a toolbox for model analysis.

Feature importance

• Generalised Linear Models

Generalised Linear Models (GLM’s) are all based on the following principle:
if you take a linear combination of your features x with the model weights w, and feed the result through a squash function f, you can use it to predict a wide variety of response variables. Most common applications for GLM’s are regression (linear regression), classification (logistic regression) or modelling Poisson processes (Poisson regression). The weights that are obtained after training are a direct proxy of feature importance and they provide very concrete interpretation of the model internals.

e.g. when building a text classifier you can plot the most important features and verify whether the model is overfitting on noise. If the most important words do not correspond to your intuition (e.g. names or stopwords), it probably means that the model is fitting to noise in the dataset and it won’t perform well on new data.

• Random forest and SVM’s

Even non-linear models such as tree based models (e.g. Random Forest) also allow to obtain information on the feature importance. In Random Forest, feature importance comes for free when training a model, so it is a great way to verify initial hypotheses and identify ‘what’ the model is learning. The weights in kernel based approaches such as SVM’s are often not a very good proxy of feature importance. The advantage of kernel methods is that you are able to capture non-linear relations between variables by projecting the features into kernel space. On the other hand, just looking at the weights as feature importance does not do justice to the feature interaction.

• Deep learning

Deep learning models are notorious for their un-interpretability due to the shear number of parameters and the complex approach to extracting and combining features. As this class of models is able to obtain state-of-the-art performance on a lot of tasks, a lot of research is focused on linking model predictions to the inputs.

Especially when moving towards even more complex systems that process text and image data, it becomes hard to interpret what the model is actually learning. The main focus in research is currently primarily on linking and correlating outputs or predictions back to the input data. While this is fairly easy in the context of linear model, it is still an unsolved problem for deep learning networks. The two main approaches are either gradient-based or attention-based.

-In gradient-based methods, the gradients of the target concept calculated in a backward pass are used to produce a map that highlights the important regions in the input for predicting the target concept. This is typically applied in the context of computer vision.

-Attention-based methods are typically used with sequential data (e.g. text data). In addition to the normal weights of the network, attention weights are trained that act as ‘input gates’. These attention weights determine how much each of the different elements in the final network output. Besides interpretability, attention within the context of the e.g. text-based question-answering also leads to better results as the network is able to ‘focus’ its attention.

LIME

Lime is a more general framework that aims to make the predictions of ‘any’ machine learning model more interpretable.

In order to remain model-independent, LIME works by modifying the input to the model locally. So instead of trying to understand the entire model at the same time, a specific input instance is modified and the impact on the predictions are monitored. In the context of text classification, this means that some of the words are e.g. replaced, to determine which elements of the input impact the predictions.

If you have any questions on interpretability in machine learning, I’ll be happy to read them in the comments. Follow me on Medium or Twitter if you want to receive updates on my blog posts!

Interpreting machine learning models was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

This blog post is the second in a series on transfer learning. You can find the first blog post, which explains the basic concept of transfer learning, here.

NLP

One of my previous blog posts discussed how a lot of NLP pipelines nowadays use word embeddings. These word embeddings are a more informative way of representing words, compared to one-hot encodings. They are widely used and different variants exist. Typically these variants differ in the corpus they originate from, such as Wikipedia, news articles, etc., and the differences in the embedding models. It is important to understand the background of these models and corpora in order to know whether transfer learning with word embeddings is sensible. People typically wouldn’t call the use of word embeddings transfer learning, yet I disagree, given the similarity with transfer learning in computer vision. Essentially, using word embeddings means that you are using a featuriser or the embedding network to convert words to informative vectors.

Even though word2vec is already 4 years old, it is still a very influential word embedding approach. Recent approaches on the other hand such as FastText have made word embeddings available in a large number of languages. Embeddings from word2vec or FastText are a significant step forwards compared to bag-of-words approaches. Nevertheless, their usefulness is typically determined by the problem domain.

Imagine you are building a news recommendation service for sales people. The sales people want to receive news on companies that could be interested in the product they are selling. The vocabulary that is used in news articles is typically fairly generic or general, meaning that a vocabulary is used that is supported by most word embeddings (depending on the corpus they are trained on). In addition, if you have the sales people collect the news articles they read for a couple of weeks, then you immediately have a large labelled corpus at your hands. By being able to reuse word embeddings the recommendation engine might perform significantly better than a simple BoW model.

On the other hand, imagine that you have to perform topic classification on legal contracts. Not just any type of legal contracts, but French legal contracts in the context of competition law. These type of datasets are typically not labelled, or only a limited set of labeled documents are available. The next section will describe why out-of-the-box transfer learning will only get you so far in this case:

• Out-Of-Vocabulary (OOV) words are words that have not been seen during the training. While word2vec and FastText are trained on, for example, Wikipedia or other copora, the vocabulary that is used is finite. During training, words that didn’t occur frequently have often been left out. That means that it is possible that domain-specific words from legal contracts in competition law are therefore not supported. When using pre-trained word embeddings, you typically check for OOV words and replace them with the UNK token (UNKnown word token) and all these words are assigned the same vector. This is highly ineffective if the corpus is domain specific, given that the domain specific words typically carry a lot of meaning. If most of the (meaning-carrying) words are replaced by UNK tokens, than the model will not be able to learn a lot.
• An alternative to the standard pre-trained word embeddings is to fine-tune the embeddings on a large unsupervised set of documents. Note that this is only an option if a large set of documents is available. This means that if you have a large corpus on competition law, you could train the word embeddings for the domain-specific words, by starting from pre-trained word embeddings for the other, more general words. Typically, starting for pre-trained word embeddings will speed up the whole process, and will make training your own word embeddings easier. Note that it is still harder using word embeddings out-of-the-box and requires some knowledge on how to prepare the corpus for word embedding training.

I highly advise you to read this excellent blog post on the current state of word embeddings. Taking into account the problems and solutions mentioned in this blog post is key to creating robust NLP systems and word embeddings when working with limited amounts of data.

Gensim, spacy and FastText are three great frameworks that allow you to quickly use word embeddings in your machine learning application. In addition, they also support the training of custom word embeddings. Check out this gensim, this spacy or this FastText tutorial to learn more!

Transfer learning in Computer Vision

Deep learning methods have led to significant successes in computer vision. Instead of having to define problem specific features manually, for example, Histogram of Oriented Gradients (HoG) features, color features, etc., deep learning allows practitioners to train models that take raw images as input.

The original complexity of feature definition has now shifted towards the complexity of defining the network. While architectures are often reused, there is no single strategy in composing network architectures. Typically, deep learning techniques have been invented and applied in research settings on enormous datasets (such as Imagenet or MS Coco). To increase performance on these large datasets, researchers have come up with network architectures with increasing depth and complexity. These architectures result in models with millions of parameters that are (typically) not scalable to small image datasets. Training an architecture such as ResNet or VGG net on a dataset with less than 5,000 images will simply lead to significant overfitting. The recent deep learning trend has lead to significant advancements, yet it seems data scientists with only small datasets have been left in the cold.

As it turns out, deep learning networks learn hierarchical feature representations (see this blog post by Distill). This means that the lower level layers learn low level features, such as edges, whereas the higher level layers learn higher level, yet uninterpretable concepts, such as shapes. This idea of hierarchical feature representations also occurs when the network is trained on different datasets, indicating that they can be reused in different problem domains.

Two approaches are used when using transfer learning on computer vision problems.

• First, if a fair amount of pictures (>1,000 images per class) is available, you can initialise a new model with the weights of a model trained on a different dataset. During training, you will then keep a number of layers fixed (typically the first convolutional layers) and you optimise the parameters of the higher level layers. The goal is to reduce the number of parameters that need to be optimised, while reusing the lower level layers. The lower level layers are most likely to be similar regardless of the problem domain, and the model has to freedom of combining higher level layers together, specific to the problem.
• Second, if only a really small number of pictures is available (<1,000), retraining an existing model will most likely still lead to overfitting in most cases. The number of parameters that needs to be optimised would simply be too large with respect to to the number of images. Regardless, as long as the data is visually similar to the images in a large dataset, than a large pre-trained network (trained on that large dataset) can be used as a featuriser. More specifically, you remove the last N layers of a large network (typically N=1 or N=2), and use the output of the large pre-trained network as feature representation of the images. This is again based on the assumption that the first layers in the pre-trained network learn problem independent features. These features can then be used with, for example, an SVM or logistic regression, similar to the traditional computer vision approach. Instead of having to manually define the features however, the pre-trained network is used as featuriser.

The API of Keras allows you to load pre-trained networks and keep several of the layers fixed during training. In the next section I will again discuss two use cases, respectively one where transfer learning is useful, and another where it isn’t.

Imagine working in wildlife preservation, and you want to classify the different animals that appear on a live camera feed. Especially if you are trying the monitor species that are near extinction, it is possible that you won’t be able to gather a lot of labelled data. Given that the pre-trained networks are often trained on wide domain of concepts (ranging from food, to animals and objects), using a pre-trained network as a featuriser or as initialiser is definitely an option.

On the other hand, imagine you need to analyse radiography images for oncologists. These images are not your typical cat-dog images, as they are the output of a scan which was performed on a patient. These images, although converted to RGB images, are typically in greyshades to illustrate the results of the scan. Although a pre-trained network is able to detect shapes and edges from RGB images, they will most likely have difficulty detecting those on radiography images as those are not in the training data of the pre-trained model. In addition, in medical scenario’s, the amount of labelled data is typically low. Several techniques exist to leverage (the potentially abundant) unlabelled data, but they typically require more work and finetuning. Typically, these techniques attempt to pre-train the weights of the classification network, by iteratively training each layer to reconstruct the images (using convolutional and deconvolutional layers). A combination of these techniques and pre-trained network is often used to improve convergence.

Both methods in computer vision mentioned above rely on an important assumption: patterns extracted in the original dataset are useful in the context of the new dataset. This usefulness is hard to quantify, yet it is an important assumption to take into account. Seismic, hyperspectral or even medical imagery shows limited similarity with the images in ImageNet. Determining which traffic sign an image contains however, relies on fairly similar patterns. Understanding the computer vision problem domain is crucial to successfully applying computer vision. By knowing the background of models (datasets, techniques, etc.) that are used in transfer learning, you can avoid wasting time during experimentation and focus on finetuning those models that might make the difference.

If you have any questions, I’ll be happy to read them in the comments. Follow me on Medium or Twitter if you want to receive updates on my blog posts!

Applying transfer learning in NLP and CV was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

Transfer learning is not a machine learning model or technique; it is rather a ‘design methodology’ within machine learning. Another type of ‘design methodology’ is, for example, active learning.

This blog post is the first in a series on transfer learning. You can find the second blog post, which discusses two applications of transfer learning here.

In a follow-up blog post I will explain how you can use active learning in conjunction with transfer learning to optimally leverage existing (and new) data. In a broad sense, machine learning applications use transfer learning when they leverage external information to improve the performance or generalisation capabilities.

Transfer Learning: A Definition

The general idea of transfer learning is to use knowledge learned from tasks for which a lot of labelled data is available in settings where only little labelled data is available. Creating labelled data is expensive, so optimally leveraging existing datasets is key.

In a traditional machine learning model, the primary goal is to generalise to unseen data based on patterns learned from the training data. With transfer learning, you attempt to kickstart this generalisation process by starting from patterns that have been learned for a different task. Essentially, instead of starting the learning process from a (often randomly initialised) blank sheet, you start from patterns that have been learned to solve a different task.

Transfer of knowledge and patterns is possible in a wide variety of domains. Today’s post will illustrate transfer learning by looking at several examples of these different domains. The goal is to incentivise data scientists to experiment with transfer learning in their machine learning projects and to make them aware of the advantages and disadvantages.

There are three reasons why I believe a good understanding of transfer learning is a critical skill as a data scientist:

• Transfer learning is essential in any kind of learning. Humans are not taught every single task or problem in order to be successful at it. Everyone gets into situations that have never been encountered, and we still manage to solve problems in an ad-hoc manner. The ability of learning from a large number of experiences, and exporting ‘knowledge’ into new environments is exactly what transfer learning is all about. From this perspective, transfer learning and generalisation are highly similar on a conceptual level. The main distinction is that transfer learning is often used for ‘transferring knowledge across tasks, instead of generalising within a specific task’. Transfer learning is thus intrinsically connected to the idea of generalisation that is necessary in all machine learning models.
• Transfer learning is key to ensure the breakthrough of deep learning techniques in a large number of small-data settings. Deep learning is pretty much everywhere in research, but a lot of real-life scenarios typically do not have millions of labelled data points to train a model. Deep learning techniques require massive amounts of data in order to tune the millions of parameters in a neural network. Especially in the case of supervised learning, this means that you need a lot of (highly expensive) labelled data. Labelling images sounds trivial, but for example in Natural Language Processing (NLP), expert knowledge is required to create a large labelled dataset. The Penn treebank for example, a Part-of-Speech tagging corpus, was 7 years in the making and required close cooperation of many trained linguists. Transfer learning is one way of reducing the required size of datasets in order for neural networks to be a viable option. Other viable options are moving towards more probabilistically inspired models, which typically are better suited to deal with limited data sets.
• Transfer learning has significant advantages as well as drawbacks. Understanding these drawbacks is vital for successful machine learning applications. Transfer of knowledge is only possible when it is ‘appropriate’. Exactly defining what appropriate means in this context is not easy, and experimentation is typically required. You should not trust a toddler that drives around in a toy car to be able to ride a Ferrari. The same principle holds for transfer learning: although hard to quantify, there is an upper limit to transfer learning. It is not a solution that fits all problem cases.

General Concepts in Transfer Learning

The Requirements of Transfer Learning

Transfer learning, as the name states, requires the ability to transfer knowledge from one domain to another. Transfer learning can be interpreted on a high level. One example is that architectures in NLP can be re-used in sequence prediction problems, since a lot of NLP problems can inherently be reduced to sequence prediction problems. Transfer learning can also be interpreted on a low level, where you are actually reusing parameters from one model in a different model (skip-gram, continuous bag-of-words, etc.). The requirements of transfer learning are on one hand problem specific and on the other one model specific. The next two sections will discuss respectively a high level and low level approach to transfer learning. Although you will typically find these concepts with different names in literature, the overarching concept of transfer learning is still present.

Multi-task Learning

In multi-task learning, you train a model on different tasks at the same time. Typically, deep learning models are used as they can be adapted flexibly.

The network architecture is adapted in such a way that the first layers are used across different tasks, followed with different task-specific layers and outputs for the different tasks. The general idea is that by training a network on different tasks, the network will generalise better as the model is required to perform well on tasks for which similar ‘knowledge’ or ‘processing’ is required.

An example in the case of Natural Language Processing is a model for which the end goal is to perform entity recognition. Instead of training the model purely on the entity recognition task, you also use it to perform part of speech classification, next word prediction, … As such, the model wil benefit from the structure learned from those tasks and the different datasets. I highly recommend Sebastian Ruder’s blogs on multi-task learning to learn more about multi-task learning.

Featuriser

One of the great advantages of a deep learning model is that feature extraction is ‘automatic’. Based on the labelled data and backpropagation, the network is able to determine the useful features for a task. The network ‘figures out’ what part of the input is important in order to, for example, classify an image. This means that the manual job of feature definition is abstracted away. Deep learning networks can be reused in other problems, as the type of features that are extracted, are often useful for other problems as well. Essentialy, in a featuriser you use the first layers of the network to determine the useful feature, but you dont use the output of the network, as it is too task-specific.

Given that deep learning systems are good at feature extraction, how can you reuse existing networks to perform feature extraction for other tasks? It is possible to feed a data sample into the network, and take one of the intermediate layers in the network as output. This intermediate layer can be interpreted as a fixed length, processed representation of raw data. Typically, the concept of a featuriser is used in the context of computer vision. Images are then fed into a pre-trained network (for example, VGG or AlexNet) and a different machine learning method is used on the new data representation. Extracting an intermediate layer as a representation of the image significantly reduces the original data size, making them more amenable for traditional machine learning techniques (for example, logistic regression or SVMs work better with a small representation of an image, such as dimension 128, compared to the original, for example, 128x128=16384 dimension).

In the next blog post I will discuss two applications of transfer learning more in depth, both of them with concrete examples!

If you have any questions, I’ll be happy to read them in the comments. Follow me on Medium or Twitter if you want to receive updates on my blog posts!

Transfer learning: leveraging insights from large data sets was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

This week, Uber AI Research released a set of five papers which are all focussed on 'neuroevolution'. The term neuroevolution refer to the optimisation of neural networks through evolutionary algorithms. The researchers posit that genetic algorithms are an effective method to train deep neural networks for reinforcement learning problems and that they outperform traditional RL approaches in some domains.

Overview

So what does this mean? Will all DNN's, ranging from supervised, to unsupervised as well as RL applications, be optimised using neuroevolution in the near future? Is neuroevolution the future of deep learning? What exactly is neuroevolution? In this blog post I will attempt to provide an introduction to neuroevolution, and compare it to the traditional backpropagation algorithm. I will also attempt to answer the aforementioned questions and situate neuroevolution techniques in the bigger DL picture.

First I will start by framing the optimisation problem, which is the core problem that backpropagation and neuroevolution try to solve. I will also attempt to make a clear distinction between the difference between supervised learning and reinforcement learning.

Next, I will discuss backpropagation and explain how it relates to neuroevolution. Given that both OpenAI and Uber AI Research just released papers on this technique, I have plenty of topics to tackle. Fortunately, as deep learning neuroevolution is in the early stages of research, the mechanics of neuroevolution still remain fairly comprehensible.

The optimisation problem

As discussed in my previous blog post, machine learning models are in essence function approximators. Whether it is classification, regression or reinforcement learning, the end goal is almost always to find a function that maps input data to output data. You use the training data to infer the parameters and hyperparameters and verify with the test data whether the approximated function performs well on unseen data.

The inputs can be manually defined features or raw data (images, text, etc.) and the outputs are either classes or labels in classification, real values in regression and actions in reinforcement learning. For this blog post we will limit the type of function approximators to deep learning networks, yet the same discussion applies to other models. The parameters that need to be inferred thus correspond to the weights and biases in the network. 'Performing well on train and test data' is expressed through objective measures, such as the log loss for classification, the mean squared error (MSE) for regression and the reward for reinforcement learning.

The core problem is thus finding the parameter settings that results in the lowest loss or the highest reward. Simple! Given an optimisation objective, i.e. the loss or the reward, that needs to be optimised as a function of the networks parameters the goal is thus to tweak the parameters in such a way that the optimisation objective is minimised or maximised.

In order to make this visual, let's use two examples. In both cases, we have plotted an optimisation objective. In the image of the parabola, the x-axis represents the single parameter of the model, and the y-axis represents the optimisation objective (e.g. on test data).

In the image below, the x and y axis represent the two parameters of the model and the z axis represents the optimisation objective (e.g. on the test data).

In reality, it is not possible to plot the 'optimisation surfaces', due to the sheer number of parameters and how they are non-linearly combined in deep learning networks. Nevertheless, the same ideas apply and the optimisation surface is typically high dimensional and complex, with many hills, cradles, valleys, etc.

The goal is now to find an optimisation technique that allows us to crawl in the optimisation surface and find the minimum or maximum. Note that the size and shape of these surfaces is related to the number of parameters, and it is infeasible to explore all options, regardless if we are working with continous or discrete parameters. The problem now has become the following: Given a random starting point in the optimisation surface, find the absolute minimum or maximum.

Deep neural networks are great function approximators (universal function approximators even to a certain extent), but they are also hard to optimise. Hard to optimise in this context means that it is very hard to find the global maximum or minimum on the ‘optimisation surface’. In the next sections I will discuss how gradient descent and neuroevolution can be used to find good solutions.

Gradient descent

The general idea of gradient descent (backpropagation) has been around for several decades. Due to the abundance of data, compute power, and novel innovations, it has become the main technique to optimise the parameters of deep learning models.

The general idea of gradient descent is the following:
-Assume you are in Paris, France, and you need to get Berlin, Germany. Europe in this case is the optimisation surface, Paris is the random starting point and Berlin is the absolute minimum or maximum.
-As you don't have a map, you ask random strangers the direction to Berlin. Some of the random strangers know where Berlin is but others don't, so while most of the times, you walk in the correct direction, it is possible that you also are going into wrong directions. As long as the strangers are more correct than false, it should work out (e.g. stochastic gradient descent, or gradient descent with minibatches).
-You walk 5 miles (the stepsize or learning rate) in the direction the stranger has pointed you to. This process is repeated until you believe you are close enough to Germany. It might turn out you just entered Germany, and you are nowhere close to Berlin (local optima). There is no way to verify whether you reached your end goal and you can only estimate based on your surroundings (the test loss or the reward).

Going back to the two visual examples, you can imagine how gradient descent works in the case of the parabola and the more complex surface. Essentially, with gradient descent you are walking down the optimisation surface. In the case of the parabola, it is straightforward, as you just have to walk down the slope. If the learning rate is too high though, you might never be able to get to the absolute minimum.

In the second example the situation is more complex. There are several hills and valleys you have to overcome in order to get to the absolute minimum. Several gradient descent variants that attempt to mimic physical behaviour such as a ball rolling down the surface with momentum (e.g. ADAM) in order to avoid getting stuck in local optima.

I highly recommend this blog post on gradient descent variants. It clearly explains and illustrates the differences between the different variants and how they solve the different problems that gradient descent faces. There are often several local optima, obstacles and different paths in this optimisation problem, and different variants of gradient descent typically try to tackle some (or all of these) problems. Nowadays, the ADAM optimiser seems to be the most influential one.

Essential to gradient descent is the computation of proper gradients that propel you towards a good solution. In supervised learning, it is possible to obtain 'high quality gradients' with relative ease through the labeled datasets. In reinforcement learning however, you are only given a sparse reward, as the random initial behaviour will not lead to a high reward. In addition this reward only occurs after a couple of actions. While the loss in classification and regression is a relatively good proxy for the function you are trying to approximate, the reward in reinforcement learning is typically not a very good proxy of the behaviour or function you want to learn.

Given that the gradients in reinforcement learning are not always of good quality, evolution algorithms have recently been used by Uber and OpenAI to improve learning.

Neuroevolution

Neuroevolution, genetic algorithms, evolution strategies all revolve around the concept of genetic evolution.

When you are doing genetic optimisation in the context of DNN optimisation, you start from an initial population of models. Typically, a model is randomly initialised, and several offspring are derived based on this initial model. In the case of DNN’s, you initialise a model (as you normally do), and you add small random vectors, sampled from a simple Gaussian distribution, to the parameters. This results in a cloud of models, which all reside somewhere on the optimisation surface. Note that this is the first important distinction with gradient descent. You start (and continue to work) with a population of models, instead of a single (point) model.

Starting from this original population, the genetic optimisation cycles start. In what follows I will describe genetic optimisation in the context of evolution strategies (ES). Evolution strategies, genetic algorithms, etc. all have slightly different approaches as to how genetic optimisation is performed.

First, a fitness evaluation is performed. Fitness evaluation corresponds with checking where the models are in the optimisation surface and determining which of the models perform best (e.g. are the most fit). Some models will perform better than others, just because of the way they have been initialised.
Next, a selection is performed based on the fitness evaluation. In evolution strategies, the (pseudo) offspring is reduced to a single model, weighted by the fitness evaluation. For DNN's the fitness is defined as the loss or the reward. Essentially, you are thus moving around the optimisation surface and using the offspring to get in the right direction. Notice that this is a second major difference with gradient descent. Instead of computing the gradients, you are setting out multiple 'antenna's' and moving in the direction that looks best. In a way, this is similar to a 'structured random' search. The end result of the selection phase is that you have a single model.
Next, reproduction and combination is performed. Concretely, the same process as in the initial phase is repeated. Based on the newly selected 'prime' model, a new set of offspring is derived. The process then continues with this offspring.
Typically, in genetic optimisation, mutation is also performed in order to improve the variety of the offspring. One example of mutation is to change how the different offspring is created (i.e. different noise levels for the different parameters).

One of the advantages of ES is that the fitness evaluation of the different models in the population can be computed on different cores (out-of-core computation). The only information that needs to be shared after fitness evaluation is their performance (a scalar value) as well as the random seed value that was used to generate the model. As a result, it is not necessary anymore to share the full network with all machines. Both OpenAI and Uber used literally hundreds and thousands of machines in order to do their experiments. With the rise of cloud computing, running these experiments becomes very scalable and is only limited by compute power.

The image below represent two of the main differences between ES and gradient descent. Multiple models are used to move around, and gradients are not calculated, rather the different models are averaged based on their performance. Optimising over a population instead of over a single model results in higher robustness properties, as shown in the Uber research, and shows similarities to Bayesian approaches to DNN optimisation.

I highly recommend having a look at the great illustrations in the Uber blog post. These illustrate how ES can be used to circumvent some of the problems that gradient descent faces (e.g. getting stuck in local optima). In essence, the evolution strategy performs a gradient approximation. While using the true gradients is better when they are available, this method does show promise when only relatively bad approximations are available for the true gradient and when exploration of the optimisation surface is required, such as in reinforcement learning scenario's.

Conclusion

The researchers at OpenAI and Uber are able to show that the 'gradient approximation' of evolution strategies leads to satisfying (but not necessarily new state-of-the-art) solutions in supervised learning scenario's. On the other hand they are able to show high performance of their methods in reinforcement learning scenario's (comparable to state-of-the-art in some domains).

Will neuroevolution be the future of deep learning? Probably not, but I do believe it shows great promises for hard optimisation problems, such as in reinforcement learning scenario's. In addition, I believe a combination of neuroevolution and gradient descent methods will lead to a significant improvement in RL performance. One downside of neuroevolution is the massive amounts of compute power that are required in order to train these systems, which might limit the democratisation of these techniques.

Given that prominent research groups are focussing on these problems, I am still excited to see what the future holds!

Gradient descent vs. neuroevolution was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.