[MUSIC PLAYING]
RAJESH THALLAM: Hello, everyone.
Thanks for joining.
This is our [INAUDIBLE] summit session
on model governance and auditability.
In this session, we'll explore the frameworks and tools that
can help simplify the process to audit, track, monitor,
and govern ML modeling, adapting to our dynamic environment,
and it'll also highlight how we can apply
more governance in practice.
This is Rajesh Thallam.
I'm a solutions architect at Google Cloud focusing
on machine learning.
Let's get started.
When you're building ML applications,
it does not stop at deploying models.
In fact, it's only the beginning.
Let's take a quick look into the [INAUDIBLE] workflow
to understand what it entails.
Often, the business problem is framed--
the workflow begins with experimentation face,
with data scientists iterating through various models,
algorithms, and developing training pipelines.
These pipelines enable data scientists to iterate quickly
to create the optimal model.
These pipelines should be treated as a software
application, and are version controlled and applied
to target environments through a sensitive process.
This pipeline is trained on production data
to generate candidate models, which are then
portioned and tracked, which are then tagged for [INAUDIBLE]
and picked up by a model deployment [INAUDIBLE],,
then goes through testing strategies,
such as A/B testing.
Finally, [INAUDIBLE] endpoint running in production
are continuously monitored for the incoming data
to identify any drift, or the models
inference themselves to detect their performance [INAUDIBLE]..
This monitoring can alert teams early
on when there is a performance degradation and act upon it.
Let's take a peek into the monitoring part.
There's a problem that occurs often for ML models.
Machine learning models are trained on past data.
Let's assume after the deployment
of the model, one of the data sources no longer gets updated.
The machine learning model will adjust to this.
And its behavior will continue to be reasonably good,
and decay gradually thereafter.
A real-world example that we observed at Google
in the past--
we deployed a pipeline that trained a new ML
model every day, but got accidentally
introduced in the serving stack, transforming a specific feature
to a default value.
Unlike other software systems, machine learning model
is resilient to data changes and did not output any error.
It generated prediction responses
with lower accuracy scores.
Since the serving data is fed back to the training group
to train the next version of the model,
the problem persisted and got worse until it was discovered.
There could be potentially more reasons
why machine learning model may not
work well after it goes live in production.
The model is static, but the world around it changes.
It might be a change in user behavior
in the app due to any recent events,
or there's a need for other signals
to monitor the model's performance.
You need monitoring processes that
can track their distributions and manually
inspect the data on occasion to reduce these kind of failures.
Well, when I say model monitoring,
our goal is to make it easy to turn
on monitoring for our model deployed on Vertex AI's
Prediction service.
Almost as easy as just flipping a switch.
Once the operation endpoint is up and running,
one can turn on a training-serving skew detection
by running a single G-code command with no need
for any extra set of tasks.
Training-serving skew measures, how different is the data
seen in production from what the model was trained on.
And prediction drift measures how changes in prediction
responds in production all the time.
There are two main measures that can be monitored
and alerted on-- feature distribution
monitoring and feature attribution monitoring.
Model monitoring compares the baseline and data distributions
observed from prediction service using distance scoring
algorithms.
When the distance score exceeds the configured threshold,
model monitoring identifies the skew or drift as anomaly.
When an anomaly is detected, an alert
is sent via email or Cloud [INAUDIBLE] via Cloud Logging.
You can then visualize and analyze the feature value
distributions from the UI and perform side-by-side
analysis of distribution and training data distribution
to diagnose the issue.
Based on the alerts, you can trigger retaining pipelines
to address the performance degradation whenever
applicable.
In addition to monitoring feature distributions,
model monitoring also supports monitoring
feature attributions.
Feature attribution explains a model's prediction
on a given input by attributing it
to features of the individual inputs.
These are typically expressed as a feature importance scores.
Under the hood, model monitoring uses Explainable AI
tooling with prominent algorithms, such as SHA,
Integrated Gradients, and Line to calculate
these attributions.
These attributions are monitored during serving
to report any significant drift relative to training
or baseline.
Another useful tool in this realm
is What-If tool, an open source tool developed at Google
to visualize and probe into your models,
and to understand the data sets and outputs of machine
learning model with minimal code.
The analysis from this tool can be helpful
during training or in creation and post training evaluation.
For example, using the tool, you can test performance
in hypothetical situations or analyze the performance
of different UI features.
You can also visualize the model behavior
across multiple models and subsets of input data
and for different machine learning fairness metrics.
All right.
Now, switching the gears.
As there are more models deployed to production,
you may likely face more challenges
managing these models and find an increasing
need for model governance.
During the experimentation phase when
prototyping and investigating modeling techniques
is a huge challenge to keep track of metadata like metrics,
parameters, and proportion of code,
data, and parameters is used across the [INAUDIBLE]..
And it's important for reproducibility of experiments.
Organizations typically struggle to prove
how a model was trained.
And most cannot reliably produce a model from its dependencies.
This becomes even more critical when operating
in a regulated environment.
There is a clear need for model governance
which helps minimize the risk to an organization
by using models.
There are multiple stakeholders with varying interests
and responsibilities in establishing a model governance
process.
For example, a data scientist who experiments
with various models and deploys them
has the responsibility of documenting
model artifacts, metrics, parameters, and the context
around the training data and model's potential use cases.
Model governance is a framework, the set
of processes defining how we manage models, manage access
control policies, comply with audit and regulations, tracking
model development, and deployment processes.
What you see here is an [INAUDIBLE] governance
lifecycle, which is broken down by stages with governance
principles, stakeholders, tools that enable necessary
processes, and expected artifacts
from each of the stages.
We'll not go into this detail, but picking up
that validation stage, which puts in checks for audit,
and reviews safety and performance metrics.
This is of significant interest to internal audit boards
who are responsible for reviewing and approving
whether a model can be deployed to production or not.
To enable the stage, there are tools such as Vertex AI Model
Registry, ML Metadata, Model Card Toolkit that
can produce artifacts to help the stakeholders to make
their decision before the model gets deployed.
Let's look into some of these tools.
Vertex AI Model Registry is a central repository
to manage the lifecycle of your machine learning models.
It [INAUDIBLE] of how and where the model was trained.
You can import the models to the repository and organize, track,
and new versions.
You can also view the historical data
for performance and for retaining other metadata
for audit or governance purposes.
Another important feature is the [INAUDIBLE] marker,
which can help stakeholders understand
at a glance which model is stable version
and ready for deployment.
This is useful when guarding the model launch process.
When a model version is ready to deploy,
I'll send it to endpoint directly from the Vertex AI
Model Registry to deploy to a targeted environment.
Vertex ML Metadata lets you record
the metadata, such as metrics, parameters, and difference
with the code, data, and artifacts
produced by ML systems.
This metadata can then be queried to help analyze, debug,
and audit performance of your machine
learning system on the artifacts that it produces.
Now, this actually enables you to compare across experiments,
to find those effective parameters and different set
of hyperparameters.
You can track the lineage of machine learning artifacts
for governance purposes, multilingual reproducibility
to read on returning workflows.
Model cards are another important artifact
to model governance.
These are short documents that help organize
essential facts of a machine learning model,
and structured way of providing context and transparency
into a model's development and performance.
Model Card Toolkit is an open-source tool
developed by Google which simplifies creation
of model cards by automating just a few lines of code,
Python code, that can be integrated into machine
learning pipeline, which generates
a shareable artifact that contains
more metadata, metrics, and key graphs.
The output is HTML or JSON files that
can be saved as artifacts as the difference in machine
learning metadata.
The next in the arsenal is Vertex AI Pipelines,
that brings together all these tools and processes
that we discussed today.
Pipelines helps you to automate, monitor, and govern
your machine learning system by orchestrating workflows
in a [INAUDIBLE] manner and enabling machine
learning operation strategies.
The core feature that enables governance
is that Pipelines automatically records and stores
workflow artifacts using Vertex [INAUDIBLE] Metadata,
and enables the lineage of workflow artifacts.
For example, a machine learning model's lineage
may include the training data, hyperparameters, and code that
was used to create the model.
And data scientists can quickly convert their experiments
in production [INAUDIBLE] workflows
by altering them using the friendly Python
SDKs based on TensorFlow extended or Kubeflow pipelines.
What we discussed today is only part
of capabilities that enables you to monitor and manage
machine learning environments.
Vertex AI is a unified platform to build, deploy, and manage
model operations at scale.
It has the necessary core building blocks
for data science, machine learning, and MLOps,
making it flexible, and of course, secure.
Three key takeaways from what we shared today.
First, machine learning lifecycle
does not stop at deploying models.
You must continuously monitor your models, because once true
does not equal forever.
Vertex AI model monitoring can get you started.
Secondly, data quality drives feature quality,
which drives model quality.
So analyze your data and [INAUDIBLE] your models
with tools like [INAUDIBLE],, and understand that model behavior
with changes in data.
And finally, model versioning and provenance
is key to reproducibility in the machine learning lifecycle.
Vertex AI has the necessary building
blocks to manage models at scale with Vertex AI
pipelines, and metadata, and model registry, and a lot more.
We have put together a few resources
to learn more about the topic and get started.
Hope you enjoyed the talk.
Thank you for listening.
[MUSIC PLAYING]