Building and programming completely self-driving cars is difficult. Tesla has a strategy where it rolls out new features step by step. Some examples:
- In 2015, there was an update of the software that made it possible to park automatically
- In 2016 came another update (in beta) that gave the opportunity to drive autonomously on highways (including lane changes to reach the right exit)
- In 2018 came automatic acceleration that is aware of obstacles
- In 2019, the car got the ability to drive autonomously a maximum of 30 meters from where it was parked by calling it through the app
How can the car learn all these new things? The answer is that Tesla collects data from all sensors that are mounted in their customers’ cars. This data, and other data that they produce on test tracks and the like, are used to build new models or artificial intelligences that can handle specific use cases.
But in many situations, it is not realistic to send data back to a central learning point. Then federated learning, or collaborative learning as it is also called, may be the best choice.
No sensitive data need to leave the device, only changes to the model
Federated learning is about machine learning that uses many individual units to train a model. The model is trained with the users’ data, without it having to leave the devices. Instead of data being sent to the cloud, it is changes to the trained model that are sent from users’ devices. The training is thus decentralized.
In this way, you can access large amounts of data to train a model, without the users risking their personal data. It can be about health apps or search engine suggestions for mobile phones, but it also opens opportunities for, for example, hospitals to be able to develop diagnostic tools with the help of each other’s data, without the need to share medical records.
What kind of applications is federated learning best suited for?
Here are three examples of areas where federated learning can often be a good option:
- Medical applications
- Financial applications
- Socially critical systems
This type of training of models is a good fit with systems that handle sensitive information, for example medical or financial data, where there is a strict set of regulations for how personal data may be handled. In critical systems, which handle socially important data or data on critical infrastructure, it is also a great advantage that the data itself does not have to leave the original system.
In such cases, it is a good solution to let changes in the model itself be sent between devices. In addition to security, it also saves a lot of bandwidth not having to send large amounts of data over the network every time the model is to be trained. Data remains safe in the user’s own system, while the model is updated. The model is then sent, in encrypted form, to other systems.
Machine learning models get better the more data they have had to train with, but in many cases it is difficult to access the large amounts of useful data that would make a model more accurate. An example is in healthcare. Training a system to analyze images to find, for example, cancerous tumors by computed tomography requires lots of such images. Of all the pictures taken, a minority show cancer. This means that most of the images are bad examples for an algorithm that should learn to find tumors. The model would be better if there were more sample images to practice on.
Here, it would be very good if the hospitals could share their images with each other to help train the model, but in practice it is not just about sharing image files with each other. By instead sending only the model, updated with information from the images that remain at each hospital, you can instead collaborate in a more efficient way. A lot of research is being done in this area and we see a huge potential to achieve many of the benefits of data sharing and open data without actually having to share data.
Security does not come automatically
In a model that is trained with federated learning, data is not automatically protected. In some cases, it may be possible to retrieve parts of the data used to train a particular model. But there are several methods to prevent this type of attack. Methods that in themselves make the model somewhat less accurate, but which guarantee that individual data cannot be derived.
With the right solution to guarantee data security, you can thus take advantage of data from a large number of devices. Another advantage is that communication is faster when only the model is sent between devices and not all data, from all devices.
How have Tesla decided to do it?
From what we have been able to read, Tesla does not seem to use federated learning. Why not? After all, there is a risk that they collect and send back images for training that may contain e.g. idetifiable persons (who have not given consent). The reason they don’t use federated learning is probably about how they process data before learning can take place. When they annotate images and mark out what is what in them, it is done with the help of human experts. It is not possible to automate this in the car. Instead, AI is used to delete people’s faces or other data that may be sensitive before the images are sent back for training.
Our recommendation
There is a lot of hype about federated learning right now. We notice this not least in various announcements that come out and when we talk to our customers. Whether federated learning is a good or bad solution ultimately depends on the specific problem to be solved. Many different factors affect whether one should do as Tesla or use distributed learning.
Do you have a problem and are thinking about data security, perhaps in medicine, finance or socially critical systems? Then we are happy to discuss our experiences both around federated learning and other solutions to ensure that your data stays safe.
