(upbeat music)
- Welcome to the Machine Learning Essentials series.
In this video, we're gonna create
a deep learning model with PyTorch.
Now, if you don't know, PyTorch is an open source
machine learning framework that accelerates the path
from research prototyping to production deployment.
It also happens to be one of my favorite
deep learning libraries because it has
a powerful tensor library,
auto differentiable computational graph,
and built in data structures
for managing data, models, and optimization.
In this video, we'll be solving a simple image
classification problem to illustrate how PyTorch is used.
In my case, since I love tacos and burritos,
I'm gonna make the model distinguish between the two.
Obviously we need to start with data.
The main classes for dealing with data are datasets,
transformations, and data loaders.
Datasets model collections of data
that are used to train a model.
Inside of these datasets, we add transformations
so that the images as they come in can be transformed
into a shape that the model will understand.
Data loaders help in loading, batching,
and transforming the data as an input to the model.
Like I said before, in this case,
we will be reading images from disk,
so we'll use a basic image folder dataset
and a standard data loader.
You can see them all right here.
We have one training dataset, one training data loader,
and some transformations for the training,
as well as the same for validation.
Let's talk about my favorite part, models.
Models can be built in several ways.
You can subclass an end up module
to encapsulate the whole thing
or you can write them directly in line
using NN sequential, both work really well.
In our case, we will use a simple inline model
that uses mobile net V2,
a well-known model that it's already been trained.
And the power of this is we can use
the model parameters that have already been learned
in other scenarios.
This is called transfer learning.
Once a model is selected
we need to choose a loss function and an optimizer
we can use to learn the appropriate model parameters.
Think of a loss function as a way
of measuring how bad the model is at it.
And think of the optimizer
as a hammer that lessens the amount
of loss that we have.
Here we will choose the cross entropy loss
and we'll use standard stochastic gradient descent
as the optimizer.
Now, if you don't know what those are,
remember the loss function measures how bad we are at it.
And the optimizer makes the badness go down.
Now we loop the data until we minimize the loss
and maximize the accuracy.
Now running this locally is great,
but it is hard to share and save the work.
Azure Machine Learning is a great way
to move a local Machine Learning run
directly into the cloud.
To run this experiment,
there are three basic concepts
we need to sort out in the cloud.
The first is storage.
The second is the environment.
And the last is the compute.
Let's talk about the thing that unifies these altogether.
The Azure Machine Learning workspace is the top
level resource for Azure Machine Learning
providing a centralized place to work
with all of the artifacts you create
when you use Azure Machine Learning.
The workspace keeps a history of all training runs,
including logs, metrics, output,
and a snapshot of your scripts.
You use this information to determine
which training run produces the best model.
And it also stores where your data is,
where your environments are,
and where compute is.
Let's start with data.
Azure Machine Learning makes it easy to connect
to your data in the cloud.
It provides an abstraction layer
over the underlying storage service,
so you can securely access and work with your data
without having to write code specific to your storage type.
Azure Machine Learning also provides a number
of amazing data capabilities,
such as interoperability with Pandas and Spark DataFrames,
versioning and tracking of data lineage,
data labeling and data drift monitoring.
Now the way it does this is through
two interesting data concepts.
The first is the data store.
And the second is the dataset.
Think of the data store as the hard drive
and the dataset as the versionable view
into your hard drive.
Let's start with a data store.
Azure Machine Learning data stores
securely keep the connection information
to your Azure storage,
so you don't have to code it into your scripts.
You can register and create a data store
to easily connect to your storage account
and access the data in your underlying
Azure storage service.
Now let's talk about datasets.
Azure Machine Learning, datasets
aren't copies of your data.
By creating a dataset, you create a reference to the data
and its storage service along with a copy of its metadata.
Because datasets are lazily evaluated
and the data remains in its existing location,
you incur no extra cost.
To interact with your data and storage,
create a dataset to package your data
into a consumable object for machine learning tasks.
You can also register the dataset
to your workspace to share and reuse it
across different experiments
without data ingestion complexities.
And the best part is that these things are versionable.
So you can have multiple versions
of a dataset to even trace a model
all the way to the data that generated it.
We've just talked about storage.
All we have left are environments and compute.
Azure Machine Learning environments
are an encapsulation of the environment
where your machine learning training actually happens.
They specify the Python packages,
environment variables, and software settings
around your training and scoring scripts.
They also specify the run times.
In our case, you can run Python, Spark or Docker.
These environments are managed and version entities
within your machine learning workspace
that enable reproducible, auditable,
and portable machine learning workflows
across a variety of compute targets.
You can use these environment objects
on your local compute to develop your training script
and you can reuse the same environment
on Azure Machine Learning compute
for model training at scale.
You can also deploy your model with that same environment
and you can revisit the environment
in which an existing model was trained.
This is amazing.
We no longer have the excuse that it ran on my computer.
So we talked about storage,
we talked about environments,
now let's talk about compute.
For compute, there are some amazing options.
An Azure Machine Learning compute instance
is a managed cloud-based workstation for data scientists.
Compute instances make it easy to get started
with Azure Machine Learning development
as well as provide management
and enterprise readiness capabilities
for IT administrators.
You can use a compute instance as you're fully configured
and management development environment
in the cloud for machine learning.
They can also be used as a compute target
for training and inferencing
for development and testing purposes.
For production grade model training though,
you should use an Azure Machine Learning compute cluster
with multi node scaling capabilities.
And for production grade model deployment,
you can use an Azure Kubernetes service cluster.
So how do we use these?
A compute target is a designated compute resource
or environment where you can run your training script
or host your service deployment.
This location might be your local machine
or a cloud-based compute resource.
Using compute targets makes it easy
for you to later change your compute environment
without having to change your code at all.
In a typical model development life cycle,
you might start by developing
and experimenting on a small amount of data.
At this stage, you use your local environment,
such as local compute or compute instance
as your compute target.
Then you can scale up to larger data
or do distributing training
by using one of our compute clusters as a compute target.
After your model is ready, you can deploy it
to a web hosting environment or IOT device
with one of these deployment compute targets as well.
The compute resources you use
for your compute targets are literally attached
to the workspace.
Compute resources, other than the local machine
are also shared by everyone in the workspace.
We've done the storage.
We've done the environments.
We've done the compute.
Now let's get to work.
Azure Machine Learning provides several ways
to train your models from code first solutions
using the SDK to low code solutions
such as automated machine learning and the visual designer.
A typical way to train models is to use
a training script and run configuration.
The run configuration provides the information needed
to configure the training environment
used to train your model.
You can specify your training script, compute target
and Azure Machine Learning environment
in your run configuration and run a training job.
That's exactly what we do for our tacos and burritos.
The best thing about running these experiments
in Azure Machine Learning
is how it stores everything related to the run.
This includes log metrics, images produced,
outputs, logs, and much, much more.
This is incredibly powerful when working with others
as well as providing transparency
for every single model that you build.
Now, machine Learning models are the primary output
of this whole process.
They're basically a file or a set of files
and they should be treated
as any other software artifact.
Model registration allows you to store
and version your models directly in the cloud
inside of your Azure Machine Learning workspace.
The model registry makes it easy to organize
and keep track of your trained model.
A registered model is a logical container
for one or more local files that make up your model.
For example, if you have a model
that is stored in multiple files,
you can register them as a single model
in your Azure Machine Learning workspace.
After registration, you can then download
or deploy the registered model
and receive all the files that were registered.
Registered models are identified by name and by version.
Each time you register a model with the same name
as an existing one, the registry increments the version.
Additionally, you can add metadata tags
that can provide additional information during registration.
These tags can then be used when searching for a model.
Azure Machine Learning supports any model
that can be loaded using Python three, five or higher.
In other words, gone are the days
where we're emailing model files to each other.
We don't have to do it anymore.
Now the best part about models is deploying them.
Train Machine Learning models can be deployed
as web services in the cloud or locally,
after all, they're your models.
And you could even deploy these models
to Azure IOT edge devices.
You can deploy these things
using either CPU's or more powerful GPU's for inferencing.
You can also use these models directly from power BI.
In order to deploy these models,
all you need to do is provide an entry script.
The entry script receives data submitted
to a deployed web service and passes it to the model.
It then takes the response returned by the model
and returns that to the client.
The script is specific to your model.
It must understand the data
that the model expects and returns.
The two things you need to accomplish this
are basically, number one,
loading the model in a function called init,
and number two, running the model
on input data using a function called run.
Finally, once the model, the entry script,
and the environment are provided,
you have a ready made endpoint for serving
with the click of a button.
Let's recap.
We've learned how to use PyTorch
as a deep learning framework to distinguish
between tacos and burritos.
We also saw how moving that to the cloud
was easy with concepts such as storage,
environment, and compute,
and what they look like in Azure Machine Learning.
Finally, we saw how to move a registered model
into an end point so that anyone could use it.
And that's it.
The only thing left for you to do
is to get started to build your next machine learning model
on Azure Machine Learning.
(soft music)