Machine Learning with Go Quick Start Guide

Hands-on techniques for building supervised and unsupervised machine learning workflows

Michael Bironneau, Toby Coleman

• Editore: Packt Publishing
• Anno: 2019
• ISBN:
  9781838551650
• Edizione: 1
• Argomento: Informatica
• Categoria: Modellazione e design di dati

This quick start guide will bring the readers to a basic level of understanding when it comes to the Machine Learning (ML) development lifecycle, will introduce Go ML libraries and then will exemplify common ML methods such as Classification, Regression, and Clustering

Key Features

• Your handy guide to building machine learning workflows in Go for real-world scenarios
• Build predictive models using the popular supervised and unsupervised machine learning techniques
• Learn all about deployment strategies and take your ML application from prototype to production ready

Book Description

Machine learning is an essential part of today's data-driven world and is extensively used across industries, including financial forecasting, robotics, and web technology. This book will teach you how to efficiently develop machine learning applications in Go.

The book starts with an introduction to machine learning and its development process, explaining the types of problems that it aims to solve and the solutions it offers. It then covers setting up a frictionless Go development environment, including running Go interactively with Jupyter notebooks. Finally, common data processing techniques are introduced.

The book then teaches the reader about supervised and unsupervised learning techniques through worked examples that include the implementation of evaluation metrics. These worked examples make use of the prominent open-source libraries GoML and Gonum.

The book also teaches readers how to load a pre-trained model and use it to make predictions. It then moves on to the operational side of running machine learning applications: deployment, Continuous Integration, and helpful advice for effective logging and monitoring.

At the end of the book, readers will learn how to set up a machine learning project for success, formulating realistic success criteria and accurately translating business requirements into technical ones.

What you will learn

• Understand the types of problem that machine learning solves, and the various approaches
• Import, pre-process, and explore data with Go to make it ready for machine learning algorithms
• Visualize data with gonum/plot and Gophernotes
• Diagnose common machine learning problems, such as overfitting and underfitting
• Implement supervised and unsupervised learning algorithms using Go libraries
• Build a simple web service around a model and use it to make predictions

Who this book is for

This book is for developers and data scientists with at least beginner-level knowledge of Go, and a vague idea of what types of problem Machine Learning aims to tackle. No advanced knowledge of Go (and no theoretical understanding of the math that underpins Machine Learning) is required.

Deploying Machine Learning Applications

In the previous chapters, we learned how to create an application that can prepare data (Chapter 2, Setting Up the Development Environment) for either a supervised (Chapter 3, Supervised Learning) or unsupervised (Chapter 4, Unsupervised Learning) ML algorithm. We also learned how to evaluate and test the output of these algorithms with the added complication that we have incomplete knowledge about the algorithm's inner state and workings, and must therefore treat it as a black box. In Chapter 5, Using Pre-Trained Models, we looked at model persistence and how Go applications can leverage models written in other languages. Together, the skills you have learned so far constitute the fundamentals required to successfully prototype ML applications. In this chapter, we will look at how to prepare your prototype for commercial readiness, focusing on aspects specific to ML applications.

In this chapter, you will cover the following topics:

• The continuous delivery feedback loop, including how to test, deploy, and monitor ML applications
• Deployment models for ML applications

The continuous delivery feedback loop

Continuous delivery (CD) is the practice of using short feedback loops in the software development life cycle to ensure that the resulting application can be released at any moment in time^[1]. While there are alternative approaches to release management, we will only consider this one because creating a meaningful, short—and therefore automated—feedback loop with ML applications presents unique challenges that are not created by alternative methodologies that may not require this degree of automation.

The CD feedback loop consists of the following process:

Fig. 1: The continuous delivery feedback loop

Developing

The development portion of the feedback loop is what we have covered so far in this book. As we argued in Chapter 5, Using Pre-Trained Models, developing ML models in Go has both advantages and disadvantages, and sometimes combining Go with other languages, such as Python, to benefit from libraries, such as Keras, can significantly shorten the development portion of the cycle. The downside is reduced maintainability and more work to test the resulting solution, as it will necessarily contain a Go–Python interface (for example).

Testing

Because humans are prone to making errors, testing the source code we create is a critical element of the development life cycle to guarantee an accurate and reliable product. Entire books have been dedicated to the subject, and it seems there are as many different approaches to software testing as there are software engineers (as an internet search for software-testing methodologies will confirm). ML applications, on the surface, are particularly difficult to test because they seem like a black box, whose output depends on the training set we provide: we feed them data, and they feed us answers, but a slight change of the train–test split or the hyperparameters could produce a different output for a given input vector. How can we determine whether the answers they provide are erroneous because the model's hyperparameters are incorrect, because the input data is corrupt, or because the model's algorithms are flawed? Or is this particular response an outlier buried in a population of otherwise acceptable responses?

In the previous chapters, we performed statistical testing of models using the validation set to measure the responses of the model to a meaningful sample of inputs, comparing them to expected output values when these were available (supervised learning). Arguably, this is the only way to test ML models for accuracy or precision because retraining them on a different sample of the dataset (or with altered hyperparameters) could produce a different output for the same input, but should not produce statistically inferior results on a large validation set with regards to the same accuracy/precision metrics. In other words, with small changes to the model, we could see large changes to the way it responds to one input vector, but its response should not be too different when tested against a large enough sample of input vectors, such as the validation set.

This has two consequences. First, the way that unit tests are usually constructed, where the developer chooses input values and asserts on the output, could break down with the slightest change to the model. Therefore, it is best not to rely on assertions based on a single response. Rather, it is better to assert using an accuracy or precision metric across a larger set, using the techniques we introduced in Chapters 3, Supervised Learning, and Chapter 4, Unsupervised Learning.

Second, there may be edge cases, where we wish to guarantee the behavior of a model, or certain responses that we wish to guarantee will never occur (not even as outlying behavior). If we cannot be sure that a black box model can achieve this, combining an ML algorithm with traditional logic is the only way to ensure that the constraints are met. For example, consider Google's recent ban of "gorilla" as a search term on Google Images in an effort to prevent some accidentally racist results from appearing^[2]. Performing statistical testing of the image classifier with gorilla images would have been difficult and would only have covered this one edge case; however, knowing what an unacceptable response was and adding constraining logic to prevent this edge case was a trivial, if embarrassing, affair. As with this example, traditional unit tests can be combined with statistical testing, with the traditional unit tests asserting on the output of the constraints while the statistical tests assert on the model output directly. An holistic strategy for ML testing thus emerges:

1. Define accuracy/precision goals for the model: This may not be as simple as coming up with a single accuracy score, as reducing false positives or false negatives may take precedence. For example, a classifier that aims to determine whether a mortgage applicant should get a loan may be required to err on the side of caution, with more false negatives tolerated than false positives, depending on the risk profile of the lender.
2. Define edge case behavior and codify this into unit tests: This may require traditional logic to restrict the output of the ML model to ensure that these constraints are met and traditional unit tests to assert on the constrained output of the ML model.

Deployment

Once the ML application has been developed and you have tested it to satisfy yourself that it works as intended, the next step in the CD life cycle is to deploy the software—that is, take steps to ensure that users are able to access it. There are different deployment models, depending on factors such as whether you are intending to run the application on your own hardware or whether you intend to use an infrastructure-as-a-service (IaaS) or platform-as-a-service (PaaS) cloud, and we will touch upon these differences in the next section. Here, we will assume that you are either running the application on your own servers or using a virtual infrastructure supplied by an IaaS provider.

ML applications can present unique challenges in deployment that are absent from simpler software, such as an HTTP server that connects to a database:

• Dependency on scientific libraries that require LAPACK or BLAS entails complex installation processes with many steps, and chances for mistakes.
• Dependency on deep-learning libraries, such as TensorFlow, entails dynamic linking to C libraries, again leading to a complex installation process, with many OS and architecture-specific steps, and chances for mistakes.
• Deep learning models may need to run on specialized hardware (for example, servers with GPUs), even for testing
• Where should ML models be persisted? Should they be committed as though they were source code? If so, how can we be sure we are deploying the correct version?

Next, we will present solutions to these challenges and a sample application that embodies these solutions.

Dependencies

Anyone who has tried to build TensorFlow or NumPy from source will sympathize with the saying that anything that can go wrong, will go wrong. A search on Google, Stack Overflow, or their respective GitHub issue pages will reveal many obscure potential issues with the build process^[3][4][5]. These are not isolated finding in the sense that the scientific computing libraries that ML applications rely on tend to be highly complex and depend on a convoluted set of other libraries that are also highly complex. An academic ML researcher might have need to build dependencies from source to benefit from a certain optimization, or perhaps because they need to modify them. On the contrary, an ML application developer must try to avoid this process and instead use prebuilt images available as Python wheels^[6], ...

Indice dei contenuti

• Title Page
• Copyright and Credits
• About Packt
• Contributors
• Preface
• Introducing Machine Learning with Go
• Setting Up the Development Environment
• Supervised Learning
• Unsupervised Learning
• Using Pretrained Models
• Deploying Machine Learning Applications
• Conclusion - Successful ML Projects
• Other Books You May Enjoy