Supervised machine learning
In the “cluster of six”, we used unsupervised machine learning, to reveal hidden structure in unlabelled data, and analyse the voting patterns of Labour Members of Parliament. In this blog post, we’ll use supervised machine learning to see how well we can predict crime in London. Perhaps not specific crimes. But we can use recorded crime summary data at London borough-level , non-personal aggregated data licensed under the Open Government Licence, to predict crime counts.
Along the way, we’ll see the pay-off from an exploration of multiple models.
Why might one want to predict crime counts? Perhaps we have the responsibility to deploy, or plan a budget for, police resources. Maybe we are considering where we might invest in additional CCTV infrastructure. Robust models can support decision-making by providing predictions grounded in facts, and are especially useful where complexity in the data is otherwise harder to unpick.
No “one size fits all”
There are a range of modelling techniques available. At one end of the spectrum, we have the more intuitive and interpretable models: Given conditions A and B, then we can anticipate outcome X. At the other end, we have more powerful and complex models where one accepts the hidden nature of their inner machinery in exchange for potentially greater predictive power.
There is no “one size fits all”, and the predictive power of each model will vary depending on the data being modelled. That alone is a good reason to consider multiple models. And I don’t mind admitting that I encountered another very good reason whilst preparing my five-model analysis for this post.
I almost abandoned the model that ultimately delivered the lowest prediction error. It was because the other models were generating stronger predictions that I questioned my execution of the fifth. The fuller, but by no means exhaustive methodology, including code, is available here.
Building familiarity with the data is an important first step. We’ll begin with 32 mini-plots; one for each London borough. Within each are the crime trends across nine major crime categories. What does this tell us?
Borough is likely to be a key predictor given the considerable variation in crime counts associated with this categorical variable. Contrast, for example, the vertical scaling for “Westminster” with “Sutton”, in the bottom-right corner.
Major crime category will also likely be a key predictor, with “theft & handling”, and “violence against the person”, associated with significantly more crime across all London boroughs.
There is also a possible interplay between borough and crime category which we may need to account for in models sensitive to interaction. This is evident where more affluent boroughs, or those attracting more visitors, such as “Kensington & Chelsea”, and “Westminster”, have significantly higher counts for “theft & handling”. Contrast these boroughs with, for example, “Lewisham”, where “violence against the person” plays a more significant role.
A summary of each potential predictor also exposes their possible influence, for example, the growth in crime count over time. (I may dedicate a future post to time-series forecasting.)
Do all four potential predictors matter?
One way to address this question is to use recursive partitioning to create a tree diagram. At the top of the tree we have 100% of the over-eleven-thousand observations. The first, and most important split, is based on the major crime category: 23% of the observations are partitioned off to the right (to node 3), for “theft and handling” (abbreviated as T&H) and “violence against the person” (VATP), with the balance branching left.
Similarly, borough appears early in the recursive partitioning where node 3 splits based on this variable.
We could go to lower levels of granularity, but our purpose here is a preliminary assessment of the most important variables. This shows that month is of lesser significance. However, we’ll keep it in our initial modelling to see if it’s significant enough to influence our models’ predictive power.
Training and testing our models
Cross validation is a comparatively simple and popular method for estimating errors in predictions. We’ll use repeated cross-validation to train the models on randomly-selected cuts of the data, and validate them on the remaining cut. This approach is designed to strengthen the models’ ability to perform well on as-yet-unseen observations.
There are many modelling choices we can make to enhance their performance, for example: The initial selection of models; how we pre-process the data; and how we utilise tuning parameters to optimise their performance. The choices made for this post, and I by no means explored every possibility, are discussed in the supporting documentation.
For the purposes of this article, we’ll jump to assessing the models’ predictions versus the known actuals to see how they performed.
Comparing predictive power
Optimal predictions sit close to, or on, the dashed line in the graphic below, i.e. where the prediction for each observation equals the actual. The Root Mean Squared Error (RMSE) measures the average differences, so should be as small as possible. And R-squared measures the correlation between prediction and actual, where 0 reflects no correlation, and 1 perfect positive correlation.
Our supervised machine learning outcomes from the CART and GLM models have weaker RMSEs, and visually exhibit some dispersion in the predictions at higher counts. Stochastic Gradient Boosting, Cubist and Random Forest have handled the higher counts better as we see from the visually tighter clustering.
It was Random Forest that produced marginally the smallest prediction error. And it was a parameter unique to the Random Forest model which almost tripped me up as discussed in the supporting documentation.
The moral of the story reinforces the value of exploring multiple models. One can’t be certain which is best adapted to the data in hand. And model comparison also provides a very helpful check and balance from which the ultimate outcome may be all the stronger.
|purrr||map; map_dfr; set_names|
|dplyr||mutate; filter; if_else; tibble; arrange; count; group_by; rename; select; summarise; as_tibble; desc; top_n|
|tidyr||gather; separate; unnest|
|stringr||str_c; str_replace; fixed; str_count; str_detect; str_pad; str_remove; str_remove_all; str_replace_all|
|rebus||lookahead; whole_word; lookbehind; one_or_more|
|caret||train; trainControl; varImp|
|modelr||spread_predictions; gather_residuals; rmse; rsquare|
|base||c; library; expand.grid; factor; seq; function; list; paste0; round; subset; sum; as.data.frame; as.integer; conflicts; cumsum; max; min; Negate; search|
|ggplot2||element_text; element_rect; element_blank; theme; ggplot; ggtitle; aes; geom_abline; labs; facet_wrap; geom_point; scale_x_continuous; geom_col; geom_text; guide_legend; guides; scale_y_continuous; scale_y_log10; aes_string; coord_cartesian; coord_flip; geom_boxplot; geom_hline; geom_jitter; geom_line; geom_smooth; scale_x_discrete|
|ggthemes||scale_colour_economist; theme_economist; economist_pal|
View the code here.