I'm leading the TensorFlow Federated in Seattle.

And I'm here to tell you about federated learning

and the platform we've built to support it.

There are two parts of this talk.

First I'll talk about federated learning, how it works and why,

and then I'll switch to talk about the platform.

All right, let's do it.

And this is a machine learning story,

so it begins with data, of course.

And today, the most exciting data out there

is born decentralized on billions of personal devices,

like cell phones.

So how can we create intelligence and better

products from data that's decentralized?

Traditionally, what we do is that there's

a server in the clouds that is hosting the machine learning

model in TensorFlow, and clients all talk to it

to make predictions on their behalf.

And as they do, the client data accumulates on the server

right next to the model.

So model and data, that's all in one place.

Very easy.

We can use traditional techniques that we all know.

And what's also great about this scenario

is that the same model is exposed to data

from all clients and so--

pushing millions of clients, and so it's very efficient.

All right.

If it's so good, why change that, right?

Well actually, in some applications,

it's not so great.

First it doesn't work offline.

There's high latency, so applications that need

fast turnaround may not work.

All these network communications consuming battery life

and bandwidth.

And some data is too sensitive, so collecting is not

an option, or too large.

Some sensitive data could be large.

OK.

What can we do?

Maybe we go to the complete other extreme.

So ditch the server in the clouds.

Now each client is its own client bubble, right?

It has its own TensorFlow run time, its own model.

And it's training.

It's grinding over its data to train

and doesn't communicate with anything.

So now, of course, nothing leaves the device.

None of the concerns from the preceding slide

apply, but you have other problems.

A single client just doesn't have enough data, very often.

It doesn't have enough data to create a good model on its own.

So this doesn't always work.

What if we bring the several back,

but the clients are actually only receiving data

from the server?

Could that work?

So if you have some proxy data on the server that's

similar to the on-device data, you could use it.

You could pre-train the model on the server,

then deploy it to clients, and then let

it potentially evolve further.

So that could work.

Except, very often, there's no good proxy data or not enough

of it for the kinds of on-device data you're interested in.

A second problem is that this here,

the intelligence we're creating is

kind of frozen in time, in the sense that, as I mentioned,

clients won't be able to do a whole lot on their own.

And why does it matter?

And here's one concrete example from actual production

application.

Consider a smart keyboard that's trying

to learn to autocomplete.

If you train a model in the server

and deploy it, now suddenly millions of people

start using a new word, what happens?

You'd think, hey, it's a strong signal, millions of people.

But if you're not one of those millions,

your phone has no clue, right?

And so it could take a lot of punching

into that phone to make it notice that something new has

happened, right?

So yeah, this is not what we want.

We really need the clients so somehow contribute back

towards the common good so they can all benefit.

Federated learning is one way to do that.

Here we start with initial model provided by the server.

This one is not pre-trained.

We don't assume we have proxy data.

It doesn't matter.

It can be just 0s.

So we send it to the client.

The client now trains it locally on its own data.

And this is more than just one step of gradient descent,

but it's also now training to convergence.

Typically, you would just make a few passes

over the data on the clients and then produce

a locally trained model and send it to the server.

And now all the clients are training independently,

but they all use the same initial model to start with.

And the server's job is to orchestrate this process

to make it happen and produce the same--

feed the same initial model to all the clients.

So now once the server collects the locally trained models

from clients, it aggregates them into

a so-called federated model.

And typically what we do is simply average the model

parameters across all clients.

So the server just adds the numbers and that's it.

So this federated model, it has been influenced by data

from our clients, right?

Because it's been influenced by the client models, and those,

in turn, have been influenced by client data.

So we do get those benefits of scale in this scenario,

so that's great.

But there's one question.

What happens to privacy?

So let's look at this closely.

First, client data never left the device.

Only the models trained on this data was shared.

So next, the server does not retain, store,

any of the client models.

It simply adds them up and then throws them away.

It deletes them, right?

So they are ephemeral.

But here they're asking how they know that this

is what the server is doing.

Maybe the server is secretly, somehow,

logging something on site.

So there are cryptographic protocols

that we can use to ensure that that's all legit.

So with those protocols, the server

will only see the final result of aggregation

that will not have access to any of your client contributions.

And we use those in practice, so hopefully

to put your mind at rest.

So the server only ever sees the final aggregate.

You can still wonder how do we know that that doesn't contain

anything sensitive.

So this is where you would use differential privacy.

In a nutshell, each client keeps its updates

and adds a little bit of noise.

So once the final aggregate emerges of the server,

there's enough noise to sort of mask out any

of the individual contributions, but there is still

enough signal to make progress.

So not to get too much into the detail,

but this is also a technique we use in production.

Differential privacy is an established and a commonly used

way to provide anonymity.

If you have any more concerns, I'll

be happy to discuss them offline.

So how does it work in practice?

Firstly, it's not enough to just do it once.

So once you produce a federated model,

you'll feed it back on the server as an initial model

for the next round, then execute many thousands

of rounds, potentially.

That's how long it takes to converge.

And so in this scenario, both clients and server have a role.

Clients are doing all the learning.

That's where all the machine learning sits.

And server is just orchestrating the process,

aggregating and also providing continuity to this process

as we move from one round to another,

because the server is what carries

the state between rounds.

And to drill into this a little bit more,

in the practical applications, clients

are not all available at the same time.

You remember those concerns I mentioned about consuming

battery life and bandwidth.

We want to give users a good experience,

so we want it to be non-disruptive.

So we will only perform training when the device is connected

into the power source on the Wi-Fi network and idles,

so that the user is not negatively affected.

And so that means, out of the billions of clients out there,

only a small fraction are available at any given

time for training.

And this is illustrated on this diagram here.

This is from an actual production system.

We can kind of see, when you track the number of rounds

per hour the server completes across time,

you can see it kind of maxes out at night,

when everyone's asleep and their phone

is connected, and beeps at lunch when everybody's punching

into their phone while eating.

So yeah.

So the clients keep coming and going.

And so that means that, as we move across rounds

from one round to another, the sort of participating clients

will change for various reasons, including that some of them

lose connectivity.

So clients can, in general, drop out at any time.

So that's why, in an actual production system when

it's deployed, there's always a client selection

phase where the exact set of participants is chosen.

And there are many factors that go into it, including

concepts about bias.

But the for this talk, all that's important to remember

is that the sort of clients in each round is different.

So in a nutshell, the characteristics

of production scenarios-- at a glance,

there are many of them-- millions, billions.

They don't talk to each other.

These are cell phones, so no peer to peer connectivity.

Communication is the bottleneck in the whole system.

Clients want to be anonymous.

And, for the most part, they're interchangeable in the sense

that, in the grand scheme of things,

whether a particular device contributed data or not,

it doesn't really affect the result in any way.

And the clients are unavailable and they

can drop out at any time.

Therefore, we have to effectively consider them

as stateless.

Even if they have some memory, there's

no guarantee when they'll be back.

So we treat them as stateless low compute nodes.

And finally, the distribution of data in clients

is very non-uniform because people defer.

So it is only for mobile devices?

No, not at all.

You could use federated learning for things

like a group of hospitals wanting

to learn something together or a group

of financial institutions.

So the general approach is the same.

Of course, the details will differ a little bit.

In this case, clients are very reliable, potentially

very capable.

But there are fewer of them.

So for some of the cryptographic protocols that we're using,

they work better when there are more clients.

And so here, you may have to work harder or use some more

specialized files.

So how well does it work in practice?

We've deployed it on Google in several applications,

including the smart keyboard that I mentioned.

So it runs in production on millions of devices.

And when you compare the performance

of an autocomplete model that learns on federated data,

it's clearly better-- a hierarchy.

We have some more user clicks than the former model trained