1/38 Introduction
2/38 Introduction

Welcome to Designing Adaptable ML systems.

3/38 Introduction

In this module, we’ll explore how to:

4/38 Introduction

Recognize the ways that a model is dependent on data

5/38 Introduction

Make cost-conscious engineering decisions

6/38 Introduction

Know when to roll back a model to an earlier version

7/38 Introduction

Debug the causes of observed model behavior

8/38 Introduction

Implement a pipeline that is immune to one type of dependency

9/38 Introduction

In the 16th century, John Donne famously wrote in one of his poems that no man is an island.

10/38 Introduction

He meant that human beings need to be part of a community to thrive.

11/38 Introduction

In software engineering terms

12/38 Introduction

we would say that few software programs adopt a monolithic island-like design.

13/38 Introduction

Instead, most software today is modular, and depends on other software

14/38 Introduction

Modular programs are:

15/38 Introduction

more maintainable,

16/38 Introduction

as well as easier to reuse,

17/38 Introduction

test,

18/38 Introduction

and fix because they allow engineers to focus on small pieces of code rather than the entire program.

19/38 Introduction

Containers make it easier to manage modular programs.

A container is an abstraction that packages applications and libraries together

20/38 Introduction

so that the applications can run on a greater variety of hardware and operating systems.

This ultimately makes hosting large applications better.

21/38 Introduction

To learn more about Kubernetes, Google’s open source container orchestration software, check out the getting started with Google Kubernetes engine course.

22/38 Introduction

But what if there was no way to identify a specific version of a library

23/38 Introduction

and you had to rely on finding similar libraries at run-time?

24/38 Introduction

Furthermore, what if someone else got to choose which version got run

25/38 Introduction

and they didn’t know or really care about your program?

26/38 Introduction

There would be no way of knowing what the run-time behavior would look like.

27/38 Introduction

Unfortunately, this is precisely the case for machine learning,

28/38 Introduction

because the run-time instructions, for example, the model weights,

29/38 Introduction

depend on the data that the model was trained on.

30/38 Introduction

Additionally, similar data will yield similar instructions.

31/38 Introduction

And finally other people including other teams and our users create our data.

32/38 Introduction

Just like in traditional software engineering, mismanaged dependencies say,

33/38 Introduction

code that assumes one set of instructions, will be called

34/38 Introduction

when another end up being called instead

35/38 Introduction

can be expensive.

36/38 Introduction

Your models’ accuracy might go down or become unstable.

37/38 Introduction

Sometimes, the errors are subtle and your team may end up spending a large proportion of its time debugging.

38/38 Introduction