Understanding Federated Learning

Aviral Jain
Skillship Vellore
Published in
4 min readFeb 24, 2022

One of the prerequisites for training a machine learning model, is the collection of data. Gathering a big dataset, training a model on the data, and running the learned model on a cloud server that users can access through various applications such as web search, translation, text production, and picture processing, is the standard procedure for developing machine learning applications. The application must transfer the user’s data to the server where the machine learning model is stored every time they wish to use it. The application formed is thus very effective and accurate, but it comes at the expense of users’ privacy. For example, an e-commerce website might require information to predict the needs of their customers, and for this, they might require data such as past orders, time spent on a particular website section, searches made by the user, etc. All this data is collected every time the user visits the website and is sent to a centralized center. This poses a risk of leaking sensitive user data. Due to this, many users don’t share their data, and as a result, the machine learning model won’t be able to train itself and won’t provide accurate predictions.

An alternative to this approach is to train a centralized model on decentralized data, and this is exactly what Federated Learning does!

What is Federated Learning?

Federated learning is an approach where instead of sending data to the model, we bring the model to the devices! The model is stored locally on each participating device. It trains itself using the user data over time and becomes better. When training is complete, the training results, such as statistical patterns, numeric parameters, etc. (and not the user data) are sent back to the server. The shared results will be aggregated on the centralized server. The data never leaves the users’ device, and hence there is no risk of leaking sensitive information. Also, the collected data is encrypted with a key that only the user has, so there is no way that the server can form the data back from the shared results.

Your phone personalizes the model locally, based on your usage [A]. Many users’ updates are aggregated [B] to form a consensus change [C] to the shared model, after which the procedure is repeated. Source

“But won’t this kill my phone battery?”

Not really! Training machine learning models is surely a resource-intensive process. But the training only takes place when the mobile phones are eligible. The devices are only eligible when they are plugged in, are on a Wi-Fi network, and are idle for a period of time. Also, the training process only takes a few minutes. So, when the devices are eligible, the process will start and a model will be loaded on the device. After the training is complete, the stored model will also be deleted!

The model will train only when the phone is not in use and is plugged in. Source

“How will you train the model if you don’t have any data?”

Simple, exactly the way we train the model! A subset of participating devices will receive the trained model, and the user data will be used to test the model. In a way, the testing is done exactly where the model is required the most! The testing results will be shared back to the server. Finally, after several iterations, an update can be rolled out with the trained machine learning model.

“There must be some limits to which this can be used!”

Yes, with all its perks, federated learning also has some limitations! If the model is too large to operate on user devices, the developer will need to come up with other solutions to protect user privacy. When the training data is on the user’s device, data engineers have no method of analyzing it and ensuring that it will be useful to the application. As a result, federated learning should only be used in applications where the user data does not require preprocessing. In federated learning, developers cannot expect users to go out of their way to label training data for the machine learning model unless results can be derived from user interactions. Hence, federated learning is more suitable for applications requiring unsupervised learning.

Applications in Real-Life

In Medical Field

Training a model for clinical purposes requires diverse datasets including patient information. Hospitals can’t share this sensitive user information and records. Hence, they use Federated Learning to train the same algorithm with diverse data from different medical institutions.

Finance and Insurance Sectors

Fraud detection systems work on machine learning algorithms and require sensitive data to train and accurately provide results. Federated learning comes into play here. The model can be trained on the mobile devices using bank records and transactions made by the user and the data will never leave users’ devices. Similar tactics can be used by insurance companies to determine if the insurance claim is true or not.

Daily-life examples

GBoard by Google (Android Keyboard) uses Federated Learning for text predictions and auto-complete features. The model is trained using user activities, keeping the data secure. Similarly, Apple’s Siri (voice assistant) uses this technique to train itself and improve its voice recognition. Federated Learning also plays a vital role in domains such as blockchain, cybersecurity and IoT.

Conclusion

The use of federated learning is growing each day, and new strategies and research are being conducted to expand its usage as it addresses some of the most common problems in training machine learning models. Apart from protecting sensitive user data, it also aggregates results and detects similar trends across a large number of users, thus, making the model more robust over time.

--

--