6 Things All Non-Technical People Should Know About Machine Learning
Non-technical people are increasingly required to understand and work with technical ideas so a basic understanding goes a long way. Technical fluency means you can ask the right questions, pre-empt technical hurdles, and manage budget and timeline expectations.
Machine learning is one such technology. What is it? In a nutshell, a name given to a group of algorithms that construct complex statistical models to predict outcomes.
Here are 6 fun facts about machine learning that, if you’re non-technical, should make sure you know enough to be dangerous.
1. Your engineers don’t write machine learning algorithms; they choose pre-written algorithms, refine them, and deploy them.
Most machine learning algorithms are written and then sent out into the technical world wide web as open source libraries. There are also some machine learning algorithms that you can pay for). Machine learning engineers read the code, prod, test, and refine these algorithms and discuss their applications in open forums.
This majority of machine learning algorithms are so-called “off the shelf”. That is, they are written and documented online by the technical community on sites like SciKit and Java Machine Learning. Machine learning engineers deploy these algorithms by downloading the code (fun fact: the code can be as short as two lines!) and associated libraries into code they write for you.
It’s rare that a company would fund the creation of new and bespoke algorithms by their engineers. Most hire engineers to deploy and refine existing algorithms. The reason is that creating new algorithms is time consuming and expensive. More often than not, the needs of the company are better served by refining the use of an existing (and widely tested and deployed) algorithm than writing one from scratch.
So who writes them? Companies like Microsoft, Amazon and Google publish machine learning algorithms for particular applications. Industry professionals and academics Coursera’s co-founder Andrew Ng also contribute.
2. Most engineers don’t need to understand how the machine learning algorithms that they deploy work.
Machine learning algorithms are likened to a “black box”. That is, you can control what goes in and you can see what goes out, but you don’t know what happens in the middle.
A good machine learning engineer doesn’t necessarily have to understand exactly what goes on in that black box. She only needs to know how different types are used, and how to refine them and deploy them effectively.
And there is no shortage of algorithm types. Say, for example, you are an online retailer. What machine learning algorithms could you make use of? It depends on what question you’re trying to answer.
When will my customer return?
If you have data on when your customers have visited in the past and want to predict when they are likely to come again, you could use a time series prediction algorithm.
What will they buy?
If you have data on the contents of prior baskets and you want to predict the contents of the next one, you could use a supervised learning algorithm.
How can I best recommend additional items for my customers to purchase at checkout?
You could use a collaborative filtering algorithm, which builds a model from users past behaviour as well as similar decisions made by other customers.
How do I know which customer behaviours are good for sales?
If you have data on what customers do on your site or in-store but don’t know which behaviours actually lead to sales you could deploy an unsupervised learning algorithm.
Most machine learning engineers have a few favourite algorithms that they prefer to work with and have expertise in deploying.
3. The art of machine learning is knowing how to define the inputs to get more accurate outputs.
Most algorithms require you to define ‘features’ for the algorithm to ingest. If you don’t identify (and don’t feed in) the key feature that impacts on the accuracy of the output, your algorithm will fail by returning a low match rate or non-verifiable results.
In fact, feature engineering is an entire field that is still far from automated. So while we’ve built machine learning algorithms and can deploy them at scale on big data, the expertise of machine learning engineers comes in the massaging of the data into an algorithm to ensure the right outputs, as well as tuning the parameters of their chosen machine learning algorithm for optimal accuracy.
And that part is still distinctly human driven.
Before you think that machine learning engineers are just glorified algorithm shoppers their work is no mean feat.
Particularly when working with very large data sets (i.e. big data), the process of figuring out which features make statistical sense to define and which are significant takes a whole lot of expertise and know-how.
For example, in a recent Kaggle competition run by Instacart to predict the contents of the subsequent shopping basket, most highly ranked entries used the XGBoost algorithm. The better ones simply did a better job of refining and deploying.
4. Machine learning algorithms need to be trained and tested.
Because they are, by definition, learning, most algorithms require ‘training data’. That is, if you’re trying to predict what a shopper will buy the next time they visit your store, you need to use their historic purchase histories to train the algorithm.
Typically, your training data would consist of, say, every basket of every shopper for 80% of your customers. The algorithm would train on that data set.
The test data set will be the remaining 20%. You’d test the algorithm by feeding it every basket (except the most recent one) and see compare the results it returns to the actual final basket contents of the 20%.
5. To understand if an algorithm has worked agree a benchmark and translate the success metric to dollars.
The success of an algorithm is its match rate to the test data. Engineers use metrics like R2, ROC, and F1 scores. An F1 score improvement from 0.5 to 0.6 may not mean anything to you but may mean months of work for an engineer.
To understand the impact of the improvement you need to make sure that you and your engineer are clear on two things:
What’s your baseline?
Ask your engineers to tell you what the score is for whatever system you are currently using, or what the score is for an unrefined algorithm.
How a score improvement translates to business metrics?
For example, an F1 score of 0.5 may mean that the algorithm is able to predict 30% of the items in the customer’s next basket. An improvement of 0.1 may equate to a 15% increase in that accuracy rate. The dollar value of that is now easy to calculate if you know the average value of your customer baskets.
6. Machine learning algorithms are not the same as statistical or heuristic models.
Plenty of people use statistical models in their businesses. This does not mean that they are using machine learning. Unless and until the model – statistical, financial, or otherwise – is not making any assumptions of the relationship between your inputs, and is fully automated and predictive it is not machine learning.
And that’s not a bad thing. Machine learning isn’t necessarily the only method that gets good results.
Effective deployment of machine learning can be time consuming and expensive and the business case needs to be iron clad.
Heuristic models – or models that rely on intuitive assumptions – are still very valuable and oftentimes highly effective. They can be as effective as machine learning algorithms, depending on the expertise you’ve applied to feature engineering and testing the machine learning algorithm.
So there you have it. These are the basic features of machine learning.
The above should help you ask your engineers and data consultants the right questions, as well as manage your team’s and manager’s expectations about timelines and costs for machine learning related projects.