Federated Learning: Learning machine perspective (part-2)

In the first part, we provided a detailed overview of federated learning including current practices and bottlenecks. In this part, we examine how we can extend it beyond a normal server-client approach. Here the edge devices known as learning machines talk to each other!

Beyond server-client approach: Learning machine perspective

…the machine should have a chance of finding things out for itself it should be allowed to roam the countryside…

– Alan Turing

The dream of developing completely self-reliant machines has always been there in the Artificial Intelligence community. Because of technological advancement and cutting edge research, they have been able to overcome different bottlenecks as well as misconceptions (like a machine can never overcome the intelligence of its creator).

In this aspect, an ideal learning machine is a machine having following properties.

  • Reasoning: there has to be some kind of brain.
  • Open: needs to deal with unexpected situation.
  • Self regulating: needs to take care of its feedback.
  • Autonomous: self educated with minimum external input or control.
  • Unsupervised: most of the time the inputs will be unlabelled.
  • Decentralized: without having any central control.
  • Cross-domain: the machine should be able to learn from multiple domains.

Let’s see how much the aforementioned Federated learning approach possesses these properties.

The edge device is exposed to unexpected inputs and can incorporate those in updating the weights. It is having autonomous behavior as the training is not governed by any external agent. Based on the training algorithm different levels of reasoning can be achieved. Some of the unsupervised problems can be implemented. We can observe that some of these can be only partially achieved. The system is not decentralized as it depends on the central entity to get the latest model parameters. Also, it’s very much problem-oriented and has a lack of ability to learn from multiple domains without external input or control.

Learning machines collaborate with each other
Figure(v). Learning machines collaborate with each other.

To make the system more decentralized, one approach is to make the edge devices collaborate with each other rather than depending on the central entity to get the latest averaged weights(as given in Figure(v)). We can imagine that different edge devices(from now on wards we refer learning machines as LM or agents) working on its own problem space and transferring the latest knowledge it acquired. This can consider as Multi-LM multitask learning.

Multi-LM multitask learning

Let us first look into transfer learning[see Handbook of Research on Machine Learning Applications and Trends: Algorithms, Methods, and Techniques] in which the direction of information flow is in one direction from source to destination task. The benefits of this approach are:

  • Higher start: The initial performance(before starting of any learning) achievable only using the transferred knowledge is higher than the case where no external knowledge is made use of.
  • Higher slope: The rate at which it fully learns the target task using the transferred knowledge is high compared to learn from scratch.
  • Higher asymptote: The final performance level achievable in the target task is better than it otherwise would be.

In multitask learning, several tasks are learning simultaneously. It’s similar to transfer learning. But there are no designated source and destination tasks. This means that knowledge can flow from any direction. Also an agent can receive knowledge from multiple sources making it more complex compared to the transfer learning.

Suppose in the context of multitasking, different tasks handle by different learning machines, we can say that it is a Multi-LM multitask learning. That’s the learning machines interact with each other and share knowledge in the learning process. There can be three varieties based on the behavior of tasks the learning machine process.

  • Many LMs learning the same tasks
  • LMs learning partly the same tasks
  • LMs learning non-overlapping tasks

Let us look at how this can adopt to the Federated learning setting. As mentioned before, we assume that there is no central entity(master node). Instead the edge devices(learning machines) interact with each other.

We have seen the unequal distribution(in both amount and quality) of data in Federated learning environments. Using multitask learning, these learning machines can interact with each other in order to overcome this. As mentioned above, these LMs can work on the same type of tasks, partially the same tasks or non-overlapping tasks. However in most of the time they get exposed to different environments. So, the learning curves will be different. In this scenario, the goal of Federated learning is to achieve optimum performance in all LMs by transferring knowledge they acquired during the interaction with respective environments.

As mentioned before, one of the main properties of Federated learning is that it is far more distributed than a data center setup. So, during the collaboration among LMs there should be strategies for effective communication.

  • Suppose LMs are performing completely different tasks there is no point in sharing the knowledge among them most of the cases. But there can also be situations where partial or complete knowledge can be shared even though LMs perform non overlapping cases.
  • In some cases there can be selective collaboration. For example, there is a set of tasks in the Federated learning environment and each task is shared among a group(group size can be as small as two) of LMs. Each group can be completely isolated from other groups and share knowledge only among members in the group.
  • In other cases, all LMs will be concentrating on performing the same tasks.

There are different approaches for information sharing with others.

  • Each LM can have a policy on what information it can share with others. The policy is either fixed or context based.
  • LMs can share the knowledge on an on-demand basis. Each LM can request others or serve others based on request.

As the distribution and quality of available data are normally different in each LMs, there can also be strategies for ensuring the quality of knowledge transfer.

  • Information can transfer only when a certain level of quality on a local model is achieved or each LMs will accept knowledge from other LMs with a certain level of model quality.
  • A more generic strategy could be, a LM can take part in Federated learning only when it achieves a certain minimum quality. But the problem with this approach is that there is a chance some LMs are never able to take part in Federated learning if they are not exposed to an environment with sufficient amount or sufficient quality of data.

Formally, in an interactive learning like this, to decide on how to delegate or adopt goals or tasks is usually governed by contracts for cooperation(LM2LM contracts). Let’s see how each type can be adopted to the Federated learning environment.

Strong Contracts
  • Strict delegation: One LM knows the dependency of another LM on it and accepts the  task.
  • Strict adoption:  There exists an agreement between two LMs. One LM knows about others adopting a goal and accepts that.

These two delegations are dependent on each other. That’s one requires another.

In the federated learning environment, LMs can adopt any of these delegations based on learning behavior or other factors. In either case, there should be some initial communications informing the policies or rules and come to an agreement. This can also be contextual based. This can have different levels. Each pair of LMs can have different agreements or a group of LMs can have a single contract or even all LMs can have the same agreement.

Weak Contracts
  • Weak delegation: In this one LM exploits others without any agreement and mildly influences others in their task.
  • Weak adoption: Here also, there is no agreement but one LM adopts goals of others.

In the case of Federated learning, to have this type of contract each LM must know about the policies, goals and sometimes even knowledge about the environment of other LMs. It’s not a good practice as it violates one of the fundamental goals of Federated learning; privacy.

Autonomy in cooperation

Closed delegation: One LM(LM1) executes exactly what other LM(LM2) has specified. Here LM1 lacks the autonomy and has no opportunity to modify or suggest the goals specified by LM2.

Open delegation: Here LM2 incompletely specifies the task and LM1 has the flexibility in adopting the goals on its own. Thus LM1 possesses autonomy in realizing the tasks.

These two types of delegations can be adopted in Federated learning settings based on different factors and can be implemented in different levels also(as mentioned under Strong contracts).

Real world scenarios

Let us see some real world scenarios where Federated learning can be employed.

Autonomous cars

Autonomous cars(also known as self-driving cars) are vehicles having the ability to sense the environment and moving without human interference. There is numerous research going on in this field by different players. Most of them are focusing their research on developing a unit of vehicle which can learn continuously using Artificial Intelligence covering thousands of kilometers. One drawback of this approach is that it will take a huge amount of time and effort to reach the optimum performance and there will be many scenarios (different types of terrain, roads, junctions, rules, signals, signs, pedestrian behaviors, behavior or style of other vehicles, etc).

Federated learning can be used in this case to provide a higher start, higher slope and higher asymptote in the learning process. Firms can use multiple vehicles(Learning machines) instead of one and let them run completely different areas. These vehicles will be exposed to different environments and learn from them. They can share the acquired knowledge with other vehicles in regular intervals(or using some scheduling algorithms). Suppose a vehicle is entering an environment which is completely new to it. There can be two situations.

  • No other vehicles enter such situation before: In this case this vehicle can learn from the environment and gain the optimum performance. Then share the information with other vehicles. Other vehicles can just use this when they face such an environment.
  • One or more other vehicle already exposed to such a situation before: In this situation, this vehicle can just use the knowledge it received from others and just surpass this part of the learning curve in a short duration.

Like this, a Federated learning approach can provide a push in one of the most promising research areas.

Smart Homes

A smart home is a building in which the system will control different components(lighting, temperature, entertainment, appliances, security, etc) of it in an efficient way[see Inside the smart home]. The main components are sensors. The problem area is very complex because if we want to say a home or building is smart, the components of it also equally and independently smart, there are numerous such possible sub components, there may be also dependency among them, possible external communication and the components are exposed to continuous human interactions.

Also, we can observe that often a new type of component is entering the market for making the life of the human being more effortless. So we can say that each smart home is a heterogeneous system consisting of a varying number of sub systems or components with frequent human interactions[see The Smart Home Concept : our immediate future].

There have been numerous research efforts going on in this field with some interesting outcomes[see Smart home research]. These research works mainly focuse on improving the performance of a single home unit using learning algorithms.

There are high chances that a smart home and its components face a new environment or conditions which is completely new or anomalous. Another situation could be the starting of the entire learning process as the learning involves estimating the correlation among different components, interaction with external sources etc. There are existing algorithms which are generic in nature and can handle such situations to an extent. Let’s examine how we can improve this using a Federated learning approach.

Let’s assume that a smart home is a heterogeneous system of LMs. These LMs communicate with each other during the learning as well as during operation phases. Some of these even completely depend on others. In the federated learning environment this heterogeneous system will connect to other similar systems. There can be two approaches in connecting the systems.

1. Single communication interface to the system

Each LM in the system shares the knowledge with this interface. To gain the knowledge other systems connect to this interface. This is different from the client-server Federated learning model. Because, here the learning machines are connected to each other and the central component(the interface) does not take part in learning, instead it just acts like a storage which can be queried. The learning machines can communicate their latest information with this.

Figure(vi). Federated Learning in Smart Homes: type I

An illustration of this approach is given in Figure(vi). Arrows represent the direction of knowledge flows. The dashed arrows between LMs show that they partially share the knowledge. Some LMs(for example LM6) act without any dependency on other LMs.

2. Single communication interface to the system

Figure(vii). Federated Learning in Smart Homes: type II

Learning machines in each system interact with similar machines in other systems. Appropriate contracts(as discussed above) should be applied before the actual communication process starts. Each system may have different policies for similar LMs. There is also a possibility that some LMs do not take part in the knowledge sharing at all. An illustration of this approach is given in Figure(vii).

The advantage of the first type system model is that it provides minimum external connection makes it more secure and ensures privacy. But there may be higher latency compared to the second one where the similar LMs in different systems are directly connected.

In both cases we can see that using Federated learning we can accelerate the learning process and reach the optimum performance early compared to otherwise. It can also extend to many other areas as well.

Summary

Current machine learning approaches require centralization of training data which invite concerns about privacy in many applications. Federated learning overcomes this without the need of the movement of data to the center node. It needs special algorithms and optimization techniques in order to deal with high latency and unreliable communication.

The existing research on Federated learning is based on a client-server approach in which the central entity(server) aggregates the model weights it received from the edge devices and learns a Federated model. In this blog we discussed a completely decentralized Federated model which is a Multi-LM multitask type in which each edge devices are learning machines. These learning machines will talk to each other during the learning process. This will help to attain the optimum model quickly compared to normal approaches.

The concept of Federated learning can be extended to many areas of machine learning. But there are also problems where Federated learning cannot be used. Considering the advantages Federated learning provided it can be employed in many real-world scenarios like Autonomous cars, Smart homes etc.

Related Articles

Federated Learning: An Overview(part-1)

Current machine learning approaches require centralization of training data which invite concerns about privacy in many applications. Federated learning overcomes this without the need of the movement of data to the center node. As it has to deal with high latency and unreliable communication special algorithms and optimization techniques are needed.

Responses

Your email address will not be published. Required fields are marked *