►
Description
Presented by: John Berryman & Luke Dramko
GitHub recommends repositories to help developers discover their next passion project, find a handy tool, or learn about a useful library. In this talk, John and Luke will give you a behind-the-scenes look at GitHub's repository recommendation system, discuss the two dominant approaches for recommendation systems, and explain how GitHub is exploring both paradigms for serving personalized repository recommendations. They'll also compare the fundamental tradeoffs in characteristics, capabilities, and costs.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
Hi
I'm
John
Berryman
a
data
scientist
at
GitHub
at
GitHub.
We
pride
ourselves
in
making
our
users
and
teams
productive,
but
we
also
love
keeping
users
engaged
and
constantly
in
the
mode
of
Discovery.
This
can
mean
becoming
a
part
of
a
new
development
Community
or
finding
a
handy
library
to
helping
your
own
projects
or
finding
an
exciting
project
to
jump
into
on
your
own.
One,
big
component
of
keeping
users
engaged
is
to
recommend
repos
based
upon
their
demonstrated
interest.
A
This
really
helps
to
drive
Discovery
and
help
our
users
become
aware
of
what
all
is
out
there.
You
can
find
your
own
personalized
repository
recommendations,
serviced
in
two
places
on
GitHub
on
the
explore
page
and
embedded
among
the
items
in
the
home
page
feed,
I,
hope,
you'll
check
them
out
in
the
next
15
minutes.
We
will
give
you
a
behind
the
scenes.
Look
at
how
repo
recommendations
work
at
GitHub.
A
We
will
cover
two
main
paradigms
for
personalized
recommendations,
content-based
recommendations
and
collaborative
filtering
recommendations
and
then
we'll
show
you
how
GitHub
is
exploring
both
of
these
approaches
for
building
high
quality,
personalized
repository
recommendations
for
our
users
and
to
do
this
I'll
turn
it
over
to
2022
summer
research,
engineer
and
PhD
student
at
Carnegie,
Mellon,
Luke
drampcom.
Thank.
B
You
John
I'll
begin
with
content-based
recommendations.
The
core
principle
of
content-based
recommendations
is
that
users
are
likely
to
be
interested
in
content.
That's
similar
to
what
they've
previously
been
interested.
In.
Let's
say
we
have
a
user
of
some
sort
of
video
streaming
service
and
that
user
has
watched
several
videos
about
wildlife.
B
If
we're
recommending
a
video
to
this
user
based
on
this
principle,
we're
most
likely
to
recommend
one
about
Wildlife
rather
than
Something
Like
Home
Improvement.
A
key
advantage
of
content-based
recommendations
is
that
they
sidestep,
what's
known
as
the
cold
start
problem,
the
cold
start
problem
occurs
when
recommendation
systems
have
trouble
recommending
new
items
that
have
just
been
added
to
the
system.
However,
one
major
drawback
of
content-based
recommendations
is
that
they
can
be
computationally
expensive,
depending
on
the
type
of
content
you're
using
to
train
the
recommendation
system
and
a
content-based
video
streaming
service.
B
It's
unlikely
that
using
video
content
itself
to
train
a
recommendation
system
will
be
feasible
because
videos
are
just
so
long
and
expensive
to
encode
at
GitHub.
The
items
we're
recommending
are
repositories.
How
do
we
do
that?
There
are
a
lot
of
features
or
combinations
of
features.
We
could
choose
from
these.
Are
things
like
the
name
and
owner
of
the
repository,
the
code
itself?
The
repositories
commits
or
pull
requests,
which
themselves
are
heterogeneous
collections
of
data
and
many
many
more.
B
We
ended
up
choosing
readme's
to
represent
repositories,
they're
meaningful,
yet
concise,
which
prevents
a
recommendation
system
from
having
a
massive
computational
footprint,
but
that's
only
part
of
the
puzzle.
How
do
we
go
from
readme's
to
recommendations
starts
with
a
Timeless
principle
of
natural
language?
You
shall
know
a
word
by
the
company.
It
keeps
in
other
words,
words
can
often
be
inferred
from
context.
B
In
this
example,
the
middle
word
is
masked
out
or
hidden
from
us,
but
based
on
the
words
around
it,
we
can
infer
that
this
word
is
software.
Machine
learning
models
can
learn
to
infer
words
from
Context
too.
The
input
to
the
model
are
the
words
around
a
specific
word
in
the
text.
Machine
learning
models
don't
work
well
with
text
directly.
B
Instead,
we
match
each
word
to
a
randomly
initialized,
real,
valued
Vector
called
embedding
each
word
gets
its
own
vector
and
those
vectors
are
trained
along
with
the
model
the
model
takes
in
these
embeddings
and
it
makes
a
prediction
as
to
what
the
missing
word
is
at
the
beginning,
the
model
is
randomly
initialized
and
is
probably
going
to
make
an
incorrect
prediction.
That's
okay!
We
can
use
that
to
our
advantage.
We
can
quantify
the
error
in
the
model's
predictions
and
use
that
information
to
adjust
the
model
a
little
bit.
B
By
doing
this
many
times
the
model
becomes
pretty
good
at
predicting
the
missing
word.
But
how
does
this
help
us?
Well,
these
embedding
vectors
get
updated
too.
Embeddings
usually
have
tens
to
thousands
of
Dimensions
here
we're
showing
an
example
of
what
this
might
look
like
in
two-dimensional
space
at
the
beginning
of
training.
Embeddings
are
randomly
initialized,
but
over
time
similar
words
tend
to
move
closer
together,
because
similar
words
tend
to
co-occur
words
that
are
dissimilar,
tend
to
be
far
apart.
B
There's
one
last
piece
to
the
puzzle:
how
do
we
represent
an
entire
readme?
We
can
enhance
this
technique
by
prepending,
a
special
word
that
indicates
the
document.
Each
piece
of
textual
content
is
from
this
technique
is
referred
to
as
doctavec
like
word,
embeddings
similar
document
embeddings
end
up
close
to
each
other.
Here's
an
actual
example.
Tensorflow
is
a
machine
learning
framework
and
nni
is
a
related
repository.
It's
a
tool
for
automating
machine
learning
operations.
B
B
Thus,
we
would
recommend
another
repository
that
the
other
user
has
seen
A
major
advantage
of
this
strategy.
Is
that
it's
agnostic
of
content?
That
is,
it
doesn't
matter
what
the
items
actually
are.
This
makes
the
strategy
especially
handy
for
situations
where
the
recommended
items
are
expensive
to
learn
from.
Unfortunately,
this
strategy
suffers
from
the
cold
start
problem,
that
is
items
newly
added
to
the
system
can't
be
recommended
accurately.
B
B
We
look
at
the
sequence
of
interactions
that
users
have
with
repositories.
These
interactions
consist
of
views,
stars
and
contributions.
The
task
is
to
predict
the
missing
Repository.
The
model
may
not
predict
the
next
repository
correctly
all
of
the
time,
but
training
the
model
in
this
way
can
still
produce
useful
embeddings.
B
Let's
take
a
look
at
an
example
from
our
system.
The
neural
compressor
and
the
nni
tool
are
both
designed
for
working
with
machine
learning.
These
end
up
close
together,
in
contrast,
lovm
a
compiler
and
Associated
tool
chain
and
a
farther
away,
because
it's
unrelated
so
far,
we've
shown
how
we
can
compute
the
similarity
between
repositories,
but
it
takes
more
to
convert
these
into
recommendations.
A
No
matter
if
we
use
the
content-based
or
collaborative
approach,
the
result
is
a
list
of
repo
similarities
from
this
building
user.
Repo
recommendations
is
pretty
straightforward:
First
We
Take
a
look
at
the
repos
that
our
users
have
demonstrated
some
Affinity
towards
via
starring
viewing
or
contributing.
Then
we
do
a
quick
look
up
to
find
related
repositories
for
each
of
these
repos.
We
do
this
for
each
of
the
user
start
repos.
A
And
finally,
once
we've
collected
enough
candidate
recommendations,
we
can
score
them
and
sort
them
based
on
the
strength
of
the
Affinity,
the
similarity
and
the
quality
of
the
repos.
Finally,
we
remove
any
repos
that
you
are
already
aware
of,
for
instance,
repos
that
you've
already
started
or
that
that
you're,
the
owner
of.
In
summary,
there
are
two
main
paradigms
for
personalized
recommendations.
Content
based
and
collaborative
and
of
these
two
collaborative
recommendations
has
showed
itself
to
be
the
clear
winner
for
repo
recommendations
at
GitHub.
A
At
first
glance,
content-based
recommendations
seem
more
appropriate
because
they
provide
recommendations
directly
based
upon
the
content
of
the
Repository.
However,
modeling
that
content
is
expensive
and
the
quality
of
the
readme's
can
vary
widely,
which
can
lead
to
some
rather
noisy
recommendations.
Collaborative
filtering
gets
around
this
by
recommending
purely
based
on
user
Behavior.
It
is
actually
agnostic
of
the
content.
Another
benefit
of
content-based
recommendations
is
that
there's
no
cold
start
problem.
Any
repo
with
a
readme
can
be
recommended.
However,
in
practice,
we
don't
find
this
to
be
a
real
problem.
A
Generally
news
about
an
exciting
new
repo
tends
to
spread
quickly
and
soon
we
have
sufficient
traffic
to
make
good
recommendations.
As
a
parting
reminder,
please
make
sure
to
check
out
your
repo
recommendations,
find
them
on
the
github.com
homepage
under
the
For
You
tab,
thanks
so
much
for
your
time
and
have
a
great
universe.
2022.