►
Description
The space of AI is growing rapidly. At this pace, it can be challenging for key AI stakeholders to identify and address social and regulatory concerns with AI, motivating the need for tools and methods to approach AI ethics challenges. A popular approach in the responsible AI space is using metadata to encode a “model card,” a versatile report detailing the configuration, ethical considerations, limitations, and quantitative analysis of an AI model. This approach can be used to enable transparency and fairness of the use case, filtering of high-quality AI models, pain point identification in AI pipelines, and help with establishing compliance and lineage. In this session, we will present our proposal and end-to-end proof of concept for metadata fields and model cards incorporated in Onnx to capture aspects of the model such as provenance & mixed precision representation.
Ria Cheruvu is AI Ethics Lead Architect at the Intel Network and Edge engineering group where she leads a team responsible for the productization of trustworthy and explainable AI technologies. She is an emerging speaker in the industry and delivered technical talks for TedX, DEFCON IoT Village, and Women in Data Science communities. Ria has a master’s degree in data science from Harvard University, and her pathfinding domains include solutions for AI security, privacy, and fairness, and explainable and responsible AI systems.
Bhargavi is a Software Engineer at Intel working on enabling and optimizing AI workloads on Intel hardware. She holds a Master's degree in Computer Science from Cornell University, she has been with Intel for past 7 years
Rodolfo (Gabe) Esteves has worked for Intel for over ten years, mostly showcasing hardware capabilities to programming languages and developer technologies. In the past few years, this has encompassed Machine Learning technologies, including ONNX. Gabe got his PhD in Computer Science from the University of Waterloo, ON, Canada.
A
So,
first,
let's
kind
of
start
out
with
what's
been
done
before
and
how
this
proposal
really
got
started.
So
the
the
first
proposal
was
really
targeted
around
enabling
machine,
readable,
ai
metadata
in
onyx
and
as
we'll
talk
about
throughout
this
presentation,
that
we
see
a
number
of
different
opportunities
for
being
able
to
enable
metadata
related
elements
as
part
of
onyx
runtime
and
and
the
broader
onyx
related
items
and
tasks
and
implementations.
A
There
was
also
some
very
specific
machine,
readable
formats
and
query
languages
that
were
proposed
as
part
of
this
roadmap.
You
know
kind
of
standard
proposal
as
part
of
this
presentation.
We
now
want
to
take
this
opportunity
to
extend
the
proposal
and
start
to
think
about
the
broader
picture,
around
model
creation
and
consumption.
A
So
as
part
of
this,
what
we're
going
to
start
off
with
is
recapping
the
motivation
and
context
think
about
why
we
need
metadata
in
the
first
place
for
responsible
ai.
We're
then
going
to
present
our
proposal
with
a
new,
concrete
end-to-end
design,
where
we
cover
the
creation,
querying
and
visualization
of
metadata
a
purpose
model
hubs
and
zoos.
A
A
Perfect,
so
to
start
us
off,
onyx
needs
responsible,
ai
and,
as
I
previously
iterated
in
the
prior
slide,
metadata
is
one
of
these
key
elements.
That's
really
coming
up
with
a
lot
of
different
concepts
tied
to
it
related
to
provenance
and
other
aspects,
but
if
we
take
a
step
back
and
start
to
look
at
what
exactly
is
metadata
the
forms
it
takes,
and
why
do
we
need
it
embedded
as
part
of
onyx?
A
We
see
that
metadata
is
a
key
enabler
of
responsible,
ai
and
explainable
ai.
Today,
again,
the
provenance
related
aspects
are
definitely
a
huge
benefit
where
you're
able
to
track
a
model
and
again
the
the
metadata
associated
with
it,
there's
also
the
characterization
of
models
as
well.
That
we'll
briefly
cover
as
part
of
this
presentation
all
of
us
may
have
encountered.
A
Multiple
forms
mean
multiple
things
and
help
with
these
two
aspects:
there's
also
the
idea
of
narrowing
down
onto
failure
modes
as
well
to
help
identify
why
and
where
an
ai
model
failed,
also
in
different
environments,
whether
that
be
offline
or
directly,
during
runtime
being
able
to
do
this
type
of
monitoring
for
pain,
point
identification
for
ai
systems
now,
the
current
emphasis
today
is
on
human,
comprehensible,
metadata
and
model
cards
are
a
very
nice
industry
standard
example
of
this.
Where
you
have
this
ethical
report
or
documentation.
A
These
different
formats
can
then
take
into
place
and
allow
you
to
start
querying
the
metadata
start
to
form
and
understand
some
trends
associated
with
the
models
and
how
they
behave.
What
are
some
of
the
characteristics
of
them,
etc
and
finally
visualize
this
bringing
it
all
back
together
for
the
human
in
the
loop
stakeholders
to
be
able
to
analyze
and
understand?
B
B
So
the
example
in
the
slide
shown
is
part
of
the
tensorflow
model
card
toolkit,
so
model
card
toolkit
is
a
collection
of
tools
to
generate
metadata
in
the
form
of
json
schema
and
it
attaches
to
tensorflow
models.
So
there
are
apis
to
visualize
and
generate
model
cards.
Let
me
help
you
go
into
the
next
slide.
B
So
onyx
protobuf
has
some
support
for
model
for
metadata
already
in
the
form
of
key
value
pairs,
as
you
see
in
the
example
in
the,
as
shown
in
the
example
in
the
slide
so
we'd
like
to
build
on
this
support
and
extend
this
functionality
to
incorporate
more
machine,
readable
metadata
format
using
rdf,
which
is
a
very
standardized
and
widely
adopted.
Industry
approach
for
representing
metadata
and
rdf
is
also
powerful.
In
the
sense
it
would
not
only
help
define
model
characteristics
but
also
establish
relationship
among
entities.
B
B
It
allows
for
querying
metadata
using
sparkle,
a
powerful
capability
that
my
colleague
gabe
will
go
over
in
the
next
few
slides,
not
only
metadata
machine,
readable,
metadata
representation
helps
in
maintaining
transparency,
but
we
believe
it's
it
would
be
very
useful
to
track
provenance.
It'll
also
help
us
answer.
B
Questions
such
as
when
the
model
when
something
goes
wrong
with
the
model
deployment
it'll
help
answer
questions
such
as
what
caused
this
model
to
have
lower
accuracy
than
expected
was
the
data
set
updated,
was
the
right
validation
or
test
data
set
used
or
who
trained
the
model
so
answering
so
this
approach
would
help
answer
such
questions.
Yeah.
Could
you
move
on
to
the
next
yeah,
so
our
initial
proposal
has
a
detailed
description
of
the
model
provenance
fields
that
we
would
like
to
include.
B
You
can
find
the
link
github
link
in
the
presentation
below
for
a
more
detailed
description
of
metadata.
For
instance,
what
training
data
set
was
used?
What
licensing
was
there?
What
frameworks
were
used
to
train
the
model
details
such
as
precision,
whether
it's
an
intake
model
or
an
fp32
model
yeah
and
I'd
like
to
hand
over
the
next
slides
to
gabe?
Who
would
be
talking
about
querying
metadata
in
detail.
C
Thank
you.
So
so
it
takes
as
you
can,
as
you
can
imagine,
the
the
like
adding
adding
metadata,
no
matter
how
informative
is
a
into
to
a
model
is,
is
only
part
of
the
is
kind
of
like
the
first
half
of
the
of
the
the
battle
like
requiring
the
metadata.
What
what
you
can
do
with
models
that
are
that
that
are
decorated
with
metadata
is
kind
of
where,
where
really
the
use
of
the
the
usefulness
of
having
of
of
having
this
extra
information
should
come
into,
should
come
into
into
play.
C
So
here
we're
we're
illustrating
the
the
kind
of
things
that
you
would
be
able
to.
The
kind
of
information
you'd
be
able
to
extract
from
models
that
have
that
have
a
rdf
rdf,
the
formatted
metadata
associated
with
them.
So
rdf
as
as
barca
be
touched
in
the
touch
briefly
on
his
he's
kind
of
like
a
development
from
the
from
from
the
cement,
the
semantic
web
and
and
it's
it
came
from
from
the
requirements
of
of
mostly
library,
library,
science
and
and
creators
of
information.
C
The
the
the
letters
of
first
unfortunable,
accessible,
interoperable
and
reusable
so
here
we're
trying
to
we're
trying
to
put
that
to
the
to
the
to
the
test
by
by
illustrating
illustrating
the
kind
of
the
kind
of
queries
that
you
could
issue
against
these.
These,
the
rdf
encoded
the
metadata
using
this
fairness
ontology.
So
here
the
first,
the
the
the
the
query,
the
the
query
at
the
the
top,
the
top
left
of
the
slide
it
just
just
goes
over.
C
Are
suitable
to
doing
an
nlp,
nlp
tasks
on
qatar
and
and
that
have
been
proven
or
that
have
been
trained,
especially
and
categories
like
that
include
sports,
for
example.
So
if
you
want
to
do
sentiment,
analysis
on
a
network
ongoing
ongoing
game
or
something
like
this
would
allow
you
to
identify
from
a
large
collection
of
models
which
which
ones
are
to
discover
those
that
that
are
that
that
that
would
satisfy
this.
C
This
use
case
the
the
the
part
of
the
of
what
what
the
the
advantages
of
rdf
it
that
that
we
find
useful
here,
is
that
it's
kind
of
infinitely
extensible.
So
this
control,
this
control
vocabulary,
is
not
limited
to.
You
know
like
like
what
it
is
that
you
want
to.
The
some
authority
has
decided
to
include
in
the
vocabulary,
but
you
can
you
can
extend
it
as
long
as
as
long
as
you
make
that
those
ontologies
also
available
on
online.
C
In
the
second
query,
the
the
to
the
left,
but
at
the
bottom,
a
provenance
task
where
you
try
to
identify
what
the
the
models,
or
or
at
least
the
available
models
associated
with
determining
where
they
who
created
them-
and
this
can
the
who
can
be
an
organization
or
a
specific,
a
specific
person
and-
and
they
group
them
by
how
big
they
are.
Where
big
is
a
measure
of
how
many
layers
they
they
have.
Of
course
like.
C
This
is
just
kind
of
like
a
not
the
only
way
to
to
to
measure
size,
so
so
so,
but
but
rdf
and
the
and
the
query
language
which,
by
the
way
like
I
should,
I
should
call
it
the
query.
Language
for
rdf
is
called
sparkle
and
it's
it's
it's
something
that
you're
likely
to
find
in
things
like
wikidata,
which
is
the
the
data.
That's
that
the
machine,
readable
version
of
the
of
wikipedia
liquid
with
the
information
that
you
would
find
in
in
info
boxes,
and
so
on.
C
The
third,
the
the
the
third
example
here
is.
It
tries
to
illustrate
like
again
like
this
extensibility
by
tracking
things
that
have
more
to
do
with.
With
response
responsible
ai,
so
if
you,
if
you
would
like
to
identify
those
models
in
your
collection
or
in
a
particular
hub
that
that
you
have
specific
and
classify
them
or
or
sort
them
by
their
their
carbon
footprint,
you
you
you
can
do
this
by
by
by
using
it
using
adding
adding
the
the
the
specific
constraint
I
react
with
you.
C
Could
you
move
to
the
next
slide,
please
so
so
for
a
specific
force.
For
for
these,
these
two
queries
out
there
they're
more
more
try
to
illustrate
more
the
responsible,
ai
and
the
mixed
precision
current
the
the
tasks
that
that
could
be
associated
with
the
metadata.
So
in
the
in
the
query
to
the
left,
it's
we
are.
C
We
are
trying
to
identify
those
those
models
that
were
trained
with
data
sets
that
that
they
have
have
private
personal
information
or
that
that
by
or
that
and
just
bear
in
mind
that
this
is.
This
is
what
the
the
the
metadata
author
has
has
stated
right
like
so
this
is,
there
is
no.
There
is
no
extra
extra.
The
the
measure
of
whether
whether
a
model
is
is
particularly
is
is
responsible.
C
Does
not
not
not
exhibit
a
particular
bias
that
those
are
facilities
that
can
be
that
can
be
that
can
be
built
on
this,
but
they
are,
but
but
right
now
we're
just
concentrating
on
on
providing
and
providing
the
the
the
foundational
blocks
to
do
so.
I
think
the
the
query
on
the
query
to
the
right
is
the
like
similar
thing
by
identifying
identifying
mixed
precision,
but
this
makes
use
of
an
an
extra
and
extra
extensively
pit
point
that
we
have
that
we
have
provided
riya.
C
C
Plc
that
make
it
make
it
that
that
provides
the
functionality
that
I
just
that
I
just
show
you
making
extending
the
hogging
phase
hub
api,
basically
by
by
allowing
the
queer
the
kind
of
queries
that
I
that
I,
that
I
showed
you
as
filters
it.
The
extending
extending
the
filtering
capability
that
that
the
calling
face
hub
api
already
already
allows.
So
we
are,
we
are
the
the
the
the
use
model
that
we
have
in
mind
is
kind
of
like
a
two-stage
use
model
where
you
first
go
from
a
large
collection
of
models.
C
You
run
this
query
and
then
you
identify
the
much
smaller
subset
that
may
be
useful
to
your
task,
and
then
you
can
do
kind
of
like
a
double
click
early,
like
it
consult
a
more
specific
information
that
may
that
that
that
can
be
displayed
in
a
different
way.
So
so
for
this
I
I'll
I'll
hand
it
hand
it
over
to
to
ria
to
show
what
the
web
information
I'm
talking
about.
A
A
That
already
is
currently
there
as
part
of
onyx
and
to
the
right.
We
also
have
an
example
of
you
know.
Some
plots
that
we
might
start
to
include
around
you
know,
model
cards
and
bringing
in
the
balance
between
what
is
machine,
readable
or
embedded
within
the
model
and
what
is
queryable
and
then
what
is
kind
of
a
document
associated
with
the
the
model,
something
that
we
found
very
intuitive.
A
As
part
of
the
hugging
face
model
hubs
as
well,
that
we're
very
interested
to
see
how
we
could
potentially
extend
so,
we
can
start
to
see
the
emergence
of
things
like
data
and
ai
quality
metrics
as
well,
not
just
our
traditional
explainable,
ai,
related
methods
to
create
a
holistic
picture
of.
You
know:
performance
profiling,
characterization
again
of
these
machine
learning
models
that
are,
you
know,
coming
from
onyx.
A
So
all
in
all,
I
do
want
to
conclude
with
the
call
to
action
and
reinforce
a
couple
of
key
themes
here.
As
I
mentioned
in
the
introduction,
we
have
been
building
on
the
proposal
that
we
presented
in
the
october
2021
meeting
in
order
to
essentially
cover
a
design
around
enabling
machine-readable
metadata
in
onyx.
A
Today
we
are
presenting
our
extension
of
this
proposal
to
consider
a
more
concrete
design,
around
model
creation
and
consumption
and
then
being
able
to
cover
the
entire
metadata
creation
querying
and
filtering
from
hubs
kind
of
workflow
being
able
to
leverage
currently
existing
onyx
infrastructure
as
a
key
benefit
of
this.
So
we
are
preparing
an
initial
strawman
implementation
and
we
have
more
updates
to
come
specifically
also
from
the
intel
side,
we're
very
interested
in
exploring
technologies
around
the
metadata
creation
part
which
we
didn't
have
too
much
time
to
get
into
here.
A
We
kind
of
jumped
into
the
querying
and
the
filtering
components
as
well
as
well
as
visualization,
but
we
have
some
technologies
that
are
coming
out
there,
particularly
also
in
relationship
to
openvino
and
onyx
as
well,
and
with
that
we
would
like
to
welcome
collaboration
and
open
dialogue.
We
want
to
know
your
thoughts
on
the
types
of
metadata
fields
that
we
might
want
to
include
how
we
might
want
to
implement
this.
What's
the
right
balance
of
transparency,
we
definitely
welcome
any
of
those
contributions
or
dialogue
to
help
develop
these
solutions.
A
Finally,
we
we
would
definitely
like
to
see
our
proposal,
which
is
available
publicly
as
a
github
issue
on
the
onyx
repository
included
as
part
of
the
onyx
1.13
spec
as
well.
So
we're
looking
forward
to
collaborate
with
this
team
to
to
make
this
a
reality
and
help
enable
a
lot
of
the
other
great
topics
being
talked
about
today.
Using
metadata
and
provenance,
and
these
related
concepts
with
that,
if
we
have
time
for
questions,
we
definitely
like
to
open
it
up,
otherwise
we're
happy
to
answer
any
offline.
Thank
you.