Method for updating a machine learing model using federated learning

The method addresses federated learning challenges by using an atlas to determine optimal merging coefficients for updated model parameters, enhancing model robustness and convergence in heterogeneous and asynchronous environments.

GB2702649APending Publication Date: 2026-06-24SAMSUNG ELECTRONICS CO LTD

Patent Information

Authority / Receiving Office
GB · GB
Patent Type
Applications
Current Assignee / Owner
SAMSUNG ELECTRONICS CO LTD
Filing Date
2025-06-27
Publication Date
2026-06-24

AI Technical Summary

Technical Problem

Federated learning is hindered by heterogeneous data distribution and varying communication delays across clients, leading to inefficiencies in data utilization and model convergence.

Method used

A method that leverages an atlas to store updated model parameters from user devices, determining optimal merging coefficients using server-side data to merge these parameters effectively, allowing asynchronous communication and handling data heterogeneity.

Benefits of technology

Enables more robust model generation by incorporating diverse data sources, improving convergence and stability, and maintaining performance despite data heterogeneity and communication delays.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

A method for updating, at a server, a global machine learning, ML, model using federated learning, comprises: receiving sets of updated model parameters from user devices S100, wherein each set of upd
Need to check novelty before this filing date? Find Prior Art

Description

[002] Many recent advancements of Artificial Intelligence, Al, rely on public datasets or selfcollected datasets, which are referred to as a centralized data regime, where data are collected and curated in advance. Although this approach enables flexibility in training a network model (e.g., shuffling, batch processing, and data normalization), it is costly to prepare. Moreover, despite the availability of many shared online datasets, they represent only a small portion of digitized data. A large body of data is scattered and stored on edge devices. For instance, in 2024, an estimated 1.94 trillion photos were taken worldwide, with smartphones accounting for 94%. This volume of data generated within a single year far exceeds the size of many publicly available image datasets. Although these decentralized datasets can potentially be used to train networks, gathering them is often challenging due to parsing costs, storage requirements, regulations, and privacy concerns. Learning decentralized data without transferring the data to a central server has become an active research area, which is referred to as a decentralized data regime. A viable solution involves moving training to distributed nodes and aggregating the trained models from them. Federated learning (FL) is a representative framework for this scenario, where a server (i.e., a central node) orchestrates a set of clients (i.e., distributed nodes) to conduct local training and aggregates their results. However, two major challenges make FL not as effective as a centralized learning method in terms of data utilization: heterogeneous data distribution and varying communication delay across clients.

[003] The present applicant has therefore identified the need for an improved federated learning process. Summary

[004] In a first approach of the present techniques, there is provided a computer-implemented method for updating, at a server, a global machine learning, ML, model using federated learning, the method comprising: receiving sets of updated model parameters from a plurality of user devices, wherein each set of updated model parameters is obtained from a user device after local updating of a local instance of the global ML model by the user device; adding the received sets of updated model parameters to an atlas that defines an optimisation space for the global ML model; during each federated learning, FL, round: identifying optimal merging coefficients for merging the sets of updated model parameters in the atlas with model parameters of the global ML model; and updating the global ML model using the identified optimal merging coefficients and each set of updated model parameters in the atlas.

[005] Advantageously, the present techniques enable more user (client) devices to participate in federated learning, which enables a more robust ML model to be generated. The present techniques make use of asynchronous FL, which allows user devices to transmit their updated model parameters at their own rate. However, asynchronous FL can cause problems because slow user devices may send updates with respect to a model that is already out-of-date. This is because they may be in the process of updating an instance of the global ML model that has already been replaced by a new instance of the global ML model on other user devices. The present techniques overcome this problem by preventing overfitting on out-of-date data.

[006] The present techniques leverage server-side data to determine, during an FL round, the optimal merging coefficients for the updated model parameters received from the user devices . This is useful because the user devices may have very different local data compared to each other and compared to the data used by the server to train the global ML model originally. Furthermore, the user devices may transmit updates with respect to different instances of the global ML model. Therefore, the present techniques work out how best to merge the updated model parameters received during each FL round, by making use of an atlas or buffer that stores the most useful updated model parameters received from client devices in that FL round or in previous rounds.

[007] The term “federated learning” is used herein to mean a machine learning, ML, technique in which multiple entities (clients / user devices) collaboratively train or update a global model while keeping their data decentralised. Typically, there are multiple FL rounds and at the start of each round the server sends the latest global ML model to the entities (clients) for local training. After completing the local training, each entity (client) sends its model update back to the server.

[008] The term “model parameters” is used herein to mean any parameters of an ML model that can be used to update a global model without having to share any local training data that is private to the client devices. The model parameters may be, for example, the weights and / or biases of a neural network or deep neural network of the ML model.

[009] The term “global ML model” is used herein to mean a model that is located on a server and which is collaboratively trained / updated by the client devices.

[010] The term “local instance of the global ML model” is used herein to mean a version of the global model which is shared with each client device by the server, and which is trained locally on the client devices using locally stored data.

[011] The term “atlas” is used herein to mean a buffer that can store sets of updated model parameters from user devices that are received during each FL round.

[012] The term “anchor” is used herein to mean an entry or index within the atlas, in which the updated model parameters are stored. Each anchor may represent an optimization direction in the optimisation space. Each anchor stores a single set of updated model parameters received from a single user device. The atlas may have a pre-defined number of anchors, e.g. 100. An empty anchor is an anchor which is not storing any model parameters.

[013] The term “optimisation space” is used herein to mean the range of adjustments that can be made to the parameters of the global ML model in order to optimise the model’s behaviour for all the client devices.

[014] The term “optimal merging coefficients” is used herein to mean the optimal coefficients of a function to aggregate the model parameters received from client devices with the parameters of the global ML model.

[015] As noted above, the atlas comprises a plurality of anchors. The step of adding the received sets of updated model parameters to an atlas may comprise: adding each set of updated model parameters to an individual or separate anchor of the atlas. As explained above, an anchor is an entry or index in which in which the updated model parameters are stored. In other words, adding a set of updated model parameters to an anchor may be alternatively expressed as storing each set of updated model parameters in a respective anchor.

[016] Adding each set of the received sets of updated model parameters to an atlas may comprise: determining, after receiving the set of updated model parameters to be added, whether an empty anchor exists in the atlas. The atlas may have a pre-defined number of anchors. Initially, at the start of the federated learning, the atlas may be empty, i.e. all of the anchors may be empty. In this case, the atlas may be filled-up by all the incoming sets of updated model parameters. At the start of an FL round, the atlas may contain anywhere between all non-empty anchors to no non-empty anchors depending on how many sets of updated model parameters have been received in previous FL rounds. In other words, if a single set of updated model parameters is received during an FL round, then this set is added to one anchor in the atlas, and this single anchor is used together with existing sets of updated model parameters in other anchors to update the global ML model. This is advantageous because it means that it is not necessary for a minimum number of updates to be received from user devices in order to perform an update of the global model during a FL round. Instead, all anchors in the atlas are used for determining the optimal merging coefficients and then using the optimal merging coefficient to create the updated global ML model at the end of the FL round.

[017] In one example, when an empty anchor is determined to exist, the method may comprise: adding the received set of updated model parameters to the empty anchor in the atlas. Thus, each set of updated model parameters received from a user device is added to the next available anchor in the atlas.

[018] Alternatively, when an empty anchor is determined not to exist, the method may comprise: calculating an importance score for each anchor in which there is a set of updated model parameters; ranking the anchors based on the calculated importance scores; removing the set of updated model parameters in the anchor having the lowest ranked importance score, to form an empty anchor for the set updated model parameters to be added; and adding the set of updated model parameters to the created empty anchor in the atlas. That is, once the atlas reaches its maximum size (i.e. the anchors are all full), the content of an anchor is removed to accommodate a new set of updated model parameters. In other words, the set of updated model parameters from the lowest ranked anchor is cleared from the atlas. If multiple set of updated model parameters is received after all the anchors are full, a corresponding number of anchors having the lowest ranked importance score are cleared. Advantageously, the content of the atlas is optimised based on how important the received sets of updated model parameters are. The larger the importance score, the more useful the set of updated model parameters is for updating the global ML model.

[019] Calculating an importance score may comprise: identifying the optimal merging coefficients; and using the optimal merging coefficient for each set of updated model parameters as the importance score. Thus, once the atlas is full, the optimal merging coefficients may be determined for the anchors. The merging coefficients for each anchor (i.e. for the set of updated model parameters stored by each anchor) may serve as the importance score, since the merging coefficients indicate the extent to which the global ML model needs to be adjusted. During federated learning, the global ML model typically converges towards an optimal global ML model. The importance score (merging coefficient) may be an indicator of whether the set of updated model parameters in each an anchor have similar characteristics or are outliers. The outlier anchors will typically be ranked lowest based on their importance scores and may thus be automatically removed from the atlas.

[020] The method may further comprise: normalising a magnitude of each parameter in each set of updated model parameters in the atlas prior to identifying the optimal merging coefficients. The presence of data heterogeneity and the asynchronous communication means that the updated model parameters received from user devices may vary in magnitude, which can lead to optimisation problems (such as over-fitting) in each FL round. Thus, advantageously, the present techniques normalise the magnitude of each parameter in each set of updated model parameters before identifying the optimal merging coefficients in each FL round.

[021] The step of identifying optimal merging coefficients may comprise: determining whether the sets of updated model parameters are obtained by local updating by user devices using in-domain local data or out-of-domain local data, wherein in-domain local data is in the same domain as data used to train the global ML model, and out-of-domain local data is in a different domain as data used to train the global ML model. The domain may be a specific field or subject matter to which the global ML model is applied. The goal of federated learning is to train / update the global ML model by achieving some consensus on how the parameters received from all the user devices are to converge. The bigger the differences between the parameters received from the user devices and the current parameters of the global ML model, the more likely it is that the differences arise from the local data being different to server-side data used to train the global ML model originally.

[022] In a first case, when the sets of updated model parameters are obtained by local updating by user devices using in-domain local data, identifying optimal merging coefficients may comprise: identifying, using any suitable loss function, e.g. cross-entropy loss, the optimal merging coefficients. In this case, the server can perform a direct search for the optimal merging coefficients using a loss function that is consistent with training performed by the user devices. Merely, as an example, the loss function £ may be used as defined by: Ci -C|A| = argmin^(Ds,cok + ^ + c where c±...qA| are the optimal merging coefficients for each anchor 1, ..., A, Ds is the indomain data, ,cok is the global ML model, are the set of model parameters in each anchor and c = [c1;..., C|A|] is the set of merging coefficients.

[023] In a second case, when the sets of updated model parameters are obtained by local updating by user devices using out-of-domain local data, identifying optimal merging coefficients may comprise: generating a new classifier head to replace a classifier head in the global ML model; and identifying optimal merging coefficients using any suitable loss function, e.g. a cross-entropy loss, for the new classifier head. The new classifier head may be denoted by i9 and the loss function by h^. In other words, the global ML model may be considered to have a global classifier head (denoted by a)he) and a global body (denoted by o)bo). Similarly, each anchor am may be considered to comprise a set of updated head parameters; am he and a set of updated body parameters am b0. Identifying optimal merging coefficients may comprise training the new classifier head to minimise the loss between labels of the training data set and labels generated using the global body of the global ML model and then identifying optimal merging coefficients for merging the global body of the global ML model with the sets of updated body parameters. This may be defined by: Q* = argmin (•) and then e M-) = [^bo + QQi.bo -;^]X

[024] The first and second cases may be combined to give a third case, when the sets of updated model parameters are obtained by local updating by user devices using both indomain local data and out-of-domain local data. In this case, identifying optimal merging coefficients may comprise: identifying, using a cross-entropy loss and the sets of updated model parameters obtained using in-domain local data, the optimal merging coefficients for merging the updated model parameters using in-domain local data with the global ML model; generating a new classifier head to replace a classifier head in the global ML model; and identifying, for the sets of updated model parameters obtained using out-of-domain local data, optimal merging coefficients using the new classifier head. The new classifier head may be used as above to identify optimal merging coefficients for merging the global body of the global ML model with the sets of updated body parameters for the sets of updated model parameters obtained using out-of-domain local data. In other words, the sets of updated head parameters may be ignored when obtaining the optimal merging coefficients for the sets of updated model parameters obtained using out-of-domain local data. When updating the global ML model using the identified optimal merging coefficients and each set of updated model parameters in the atlas, both head and body parameters may be used for both in-domain and out-ofdomain obtained sets of updated model parameters.

[025] Receiving a set of updated model parameters from at least some user devices of a plurality of user devices may comprise: receiving a set of updated model parameters from at least some user devices at any time. That is, the present techniques utilise asynchronous communication and updates received from user devices do not fail. If an update is received just after the server has already performed an update of the global ML model and shared the new global ML model with the user devices, even though the update is performed with respect of an older version of the global ML model, the update may be added to the atlas and other sets of parameters may be deleted or removed from anchors based on their ranked importance scores to make space as needed.

[026] Identifying optimal merging coefficients may comprise: identifying optimal merging coefficients using the atlas at the end of a pre-defined time frame from the global ML model being sent to the user devices (e.g. after a fixed time has elapsed from the start of an FL round). As noted above, whatever is in the atlas at the end of the time frame is used to perform the update of the global ML model. In other words, sets of updated model parameters may have been received from some but not all user devices which received the global ML model for updating at the start of the FL round. Any updates received after this time frame may be added to the atlas for the new / next FL round instead of simply being rejected. Moreover, the atlas may also contain sets of updated model parameters received from previous rounds when the optimal merging coefficients are identified.

[027] The method may further comprise: transmitting, after the updating, the updated global ML model to all user devices of the plurality of user devices, wherein the updated global ML model forms a new local instance of the global ML model on each user device.

[028] In a second approach of the present techniques, there is provided a server for updating a global machine learning, ML, model using federated learning, the server comprising: storage storing a global ML model and a model atlas; and at least one processor coupled to memory, configured for: receiving sets of updated model parameters from a plurality of user devices, wherein each set of updated model parameters is obtained from a user device after local updating of a local instance of the global ML model by the user device; adding the received sets of updated model parameters to an atlas that defines an optimisation space for the global ML model; during each FL round; during each federated learning, FL, round: identifying optimal merging coefficients for merging the sets of updated model parameters in the atlas with model parameters of the global ML model; and updating the global ML model using the identified optimal merging coefficients and each set of updated model parameters in the atlas.

[029] The features described above with respect to the first approach apply equally to the second approach and therefore, for the sake of conciseness, are not repeated.

[030] The server comprises at least one processor and memory storing instructions that, when executed by the at least one processor individually or collectively, cause the server to perform the steps described above.

[031] In a third approach of the present techniques, there is provided a computer-implemented method for updating, at a client device, a global machine learning, ML, model using federated learning, the method comprising: receiving, at the start of a federated learning, FL, round, a local instance of the global ML model for local training from a server; training the local instance of the global ML model using client data stored on the client device; and transmitting, after the training, a set of updated model parameters for the trained local instance of the global model to the server.

[032] In a related approach of the present techniques, there is provided a computer-readable storage medium comprising instructions which, when executed by at least one processor, causes the processor to carry out any of the methods described herein.

[033] In the cases where the present techniques are implemented or executed on a device comprising multiple processors, the present techniques may be implemented by one or more of the multiple processors. That is, the present techniques may be implemented by or executed by the processors individually or collectively.

[034] As will be appreciated by one skilled in the art, the present techniques may be embodied as a system, method or computer program product. Accordingly, present techniques may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects.

[035] Furthermore, the present techniques may take the form of a computer program product embodied in a computer readable medium having computer readable program code embodied thereon. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[036] Computer program code for carrying out operations of the present techniques may be written in any combination of one or more programming languages, including object oriented programming languages and conventional procedural programming languages. Code components may be embodied as procedures, methods or the like, and may comprise subcomponents which may take the form of instructions or sequences of instructions at any of the levels of abstraction, from the direct machine instructions of a native instruction set to high-level compiled or interpreted language constructs.

[037] Embodiments of the present techniques also provide a non-transitory data carrier carrying code which, when implemented on a processor, causes the processor to carry out any of the methods described herein.

[038] The techniques further provide processor control code to implement the abovedescribed methods, for example on a general purpose computer system or on a digital signal processor (DSP). The techniques also provide a carrier carrying processor control code to, when running, implement any of the above methods, in particular on a non-transitory data carrier. The code may be provided on a carrier such as a disk, a microprocessor, CD- or DVD-ROM, programmed memory such as non-volatile memory (e.g. Flash) or read-only memory (firmware), or on a data carrier such as an optical or electrical signal carrier. Code (and / or data) to implement embodiments of the techniques described herein may comprise source, object or executable code in a conventional programming language (interpreted or compiled) such as Python, C, or assembly code, code for setting up or controlling an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array), or code for a hardware description language such as Verilog (RTM) or VHDL (Very high speed integrated circuit Hardware Description Language). As the skilled person will appreciate, such code and / or data may be distributed between a plurality of coupled components in communication with one another. The techniques may comprise a controller which includes a microprocessor, working memory and program memory coupled to one or more of the components of the system.

[039] It will also be clear to one of skill in the art that all or part of a logical method according to embodiments of the present techniques may suitably be embodied in a logic apparatus comprising logic elements to perform the steps of the above-described methods, and that such logic elements may comprise components such as logic gates in, for example a programmable logic array or application-specific integrated circuit. Such a logic arrangement may further be embodied in enabling elements for temporarily or permanently establishing logic structures in such an array or circuit using, for example, a virtual hardware descriptor language, which may be stored and transmitted using fixed or transmittable carrier media.

[040] In an embodiment, the present techniques may be realised in the form of a data carrier having functional data thereon, said functional data comprising functional computer data structures to, when loaded into a computer system or network and operated upon thereby, enable said computer system to perform all the steps of the above-described method.

[041] The method described above may be wholly or partly performed on an apparatus, i.e. an electronic device, using a machine learning or artificial intelligence model. The model may be processed by an artificial intelligence-dedicated processor designed in a hardware structure specified for artificial intelligence model processing. The artificial intelligence model may be obtained by training. Here, "obtained by training" means that a predefined operation rule or artificial intelligence model configured to perform a desired feature (or purpose) is obtained by training a basic artificial intelligence model with multiple pieces of training data by a training algorithm. The artificial intelligence model may include a plurality of neural network layers. Each of the plurality of neural network layers includes a plurality of weight values and performs neural network computation by computation between a result of computation by a previous layer and the plurality of weight values.

[042] As mentioned above, the present techniques may be implemented using an Al model. A function associated with Al may be performed through the non-volatile memory, the volatile memory, and the processor. The processor may include one or a plurality of processors. At this time, one or a plurality of processors may be a general purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and / or an Al-dedicated processor such as a neural processing unit (NPU). The one or a plurality of processors control the processing of the input data in accordance with a predefined operating rule or artificial intelligence (Al) model stored in the non-volatile memory and the volatile memory. The predefined operating rule or artificial intelligence model is provided through training or learning. Here, being provided through learning means that, by applying a learning algorithm to a plurality of learning data, a predefined operating rule or Al model of a desired characteristic is made. The learning may be performed in a device itself in which Al according to an embodiment is performed, and / o may be implemented through a separate server / system.

[043] The Al model may consist of a plurality of neural network layers. Each layer has a plurality of weight values, and performs a layer operation through calculation of a previous layer and an operation of a plurality of weights. Examples of neural networks include, but are not limited to, convolutional neural network (CNN), deep neural network (DNN), recurrent neural network (RNN), restricted Boltzmann Machine (RBM), deep belief network (DBN), bidirectional recurrent deep neural network (BRDNN), generative adversarial networks (GAN), and deep Q-networks.

[044] The learning algorithm is a method for training a predetermined target device (for example, a robot) using a plurality of learning data to cause, allow, or control the target device to make a determination or prediction. Examples of learning algorithms include, but are not limited to, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning. Brief description of the drawings

[045] Implementations of the present techniques will now be described, by way of example only, with reference to the accompanying drawings, in which:

[046] Figure 1A shows a schematic diagram of a centralised Al system;

[047] Figure 1B shows a schematic diagram of an alternative centralised system;

[048] Figure 2A is a schematic diagram illustrating a synchronous set-up in federated learning;

[049] Figure 2B is a schematic diagram illustrating an asynchronous set-up in federated learning, and specifically the asynchronous communication mechanism;

[050] Figure 3A shows a diagram of a centralised system;

[051] Figure 3B shows a diagram of a naive distributed system;

[052] Figure 3C shows a diagram of the present hybrid system;

[053] Figure 3D shows a schematic diagram of the present techniques;

[054] Figure 4 shows Algorithm 1 which is implemented by the central server;

[055] Figure 5 shows Algorithm 2 which is implemented by a client / user device;

[056] Figure 6 is a flowchart of example steps for updating, at a server, a machine learning, ML, model using federated learning;

[057] Figure 7 is a block diagram of a system for updating a machine learning, ML, model using federated learning;

[058] Figure 8 is a table of experimental results showing comparisons for in-domain availability;

[059] Figure 9 shows convergence plots for in-domain availability using ResNet18 and CIFAR-10;

[060] Figure 10 shows convergence plots for out-of-domain availability using ResNet18 and CIFAR-10;

[061] Figure 11 is a table of experimental results showing comparisons for out-of-domain availability;

[062] Figure 12 is a table showing the analysis of Feddle components for in-domain and out-of-domain data availability using ResNet18 and CIFAR-10 dataset with the scenario Dir(0.1), N(20);

[063] Figures 13A and 13B show the impact of atlas size on performance when using, respectively, in-domain server-side data, and out-of-domain server-side data; and

[064] Figures 14A and 14B show the impact of the validation dataset size (in-domain serverside data) on performance when using, respectively, Dir(0.1), N(20), and Dir(0.3), N(5). Detailed description of the drawings

[065] Broadly speaking, embodiments of the present techniques provide a method for updating a machine learning, ML, model using federated learning. In particular, the present techniques make use of asynchronous FL, which allows user devices to transmit their updated model parameters at their own rate. Server-side data is leveraged to determine the optimal merging coefficients for aggregating the updated model parameters during an FL round. This is useful because the user devices may have very different local data compared to each other and compared to the data used by the server to train the global ML model originally. Furthermore, the user devices may transmit updates with respect to different instances of the global ML model. Therefore, the present techniques work out how best to merge the updated model parameters received during each FL round, by making use of an atlas or buffer that stores the most useful updated model parameters received from client devices.

[066] Users in different parts of the world typically have different data characteristics. For example, considering just the photos that people may take of their food or home, these photos will likely vary depending on where the people are in the world. As a result, the outputs of Al systems can be adversely affected and achieve low-accuracy, because either, global data characteristics can be only learned by Al systems or, Al systems can overfit to dominant samples and ignore local data characteristics.

[067] Figure 1A shows a schematic diagram of a centralised Al system. One possible solution to the above-mentioned problem is to update centralised Al systems using personal / local data from users. Usually, this involves obtaining copies of users’ personal data, storing it on a central server and using this personal data to update an Al model centrally. The updated Al model can then be provided to all users. However, this solution violates user privacy and is not practical for security reasons.

[068] Figure 1B shows a schematic diagram of an alternative centralised system. Here, each user updates their local instance of an Al model (i.e. the model they are running on their own devices) using their own personal / local data. Then, the updated parameters of their model can be shared with the centralised server, so that the global Al model can be updated using these parameters. This is advantageous over the technique in Figure 1A because it does not require users’ personal data to be shared with the central server - only the updated parameters of their local Al model are shared. The parameters received from users can then be used to update the global Al model, and the updated global Al model can be provided to all users. User privacy is preserved. This sort of approach is known as Federated Learning.

[069] Figure 2A is a schematic diagram illustrating a synchronous set-up in federated learning, while Figure 2B is a schematic diagram illustrating an asynchronous set-up in federated learning. When users update their local models at the same time instance, this is known as Synchronous Federated Learning (Figure 2A). However, in practice, all users cannot be in sync and update their local models, particularly as often updates will occur when the devices running the models are not busy doing other things (e.g. at night / while a user is asleep). This is known as Asynchronous Federated Learning (Figure 2B), which can be a problem because the aggregation of updated parameters by the central server often fails.

[070] As mentioned above, two challenges arise during federated learning: fully centralised data regimes and fully decentralised data regimes. Figure 3A shows a diagram of a centralised system and Figure 3B shows a diagram of a naive distributed (decentralised) system. It is observed that, in practice, a third hybrid data regime often occurs. Figure 3C shows a diagram of this hybrid system. In this scenario, the server possesses some data, while a large amount of data is scattered among the clients. It is argued that hybrid data regime is common in practice, as the server or trusted executive environments (TEE) held by the server can access data through various means: • In-Domain Data Availability: 1) Existing collected data: There are various public datasets that could align with the distributed learning task. Additionally, companies often collect user data based on the user agreement associated with a product. 2) Incentive mechanisms: Clients can contribute a portion of their data to the server in exchange for incentives. 3) Trusted executive environment (TEE): A TEE can be set up at the server, allowing the clients to transmit a portion of their data to the TEE, which the server manages but cannot access. • Out-of-Domain Data Availability: In this scenario, the server leverages datasets whose domains differ to the domain of the clients’ data (e.g., different class labels) to guide the learning of decentralized data. This setup is applicable for a broad range of use cases.

[071] The present techniques seek to answer the following question: Is it possible to unlock the value of a large amount of decentralized data under the guidance of some data at the server?

[072] The present techniques build upon the fundamental distributed training mechanism of FL, where clients perform training on their own data and transmit their model updates to the server for aggregation. The focus is on addressing the challenges posed by data heterogeneity and asynchronous communication, where the server must handle delayed model updates due to the asynchronous mechanism. To tackle these challenges in hybrid data regime, the present techniques introduce Federated Dual Learning (Feddle), a framework that extends traditional FL by enabling the server to search for optimal merging coefficients based on diverse data availability patterns. The present techniques shift the focus away from the traditional client privacy protection in FL research and towards improving the utilization of decentralized data in hybrid regimes. Importantly, since Feddle adheres to the basic FL framework, it can be integrated with existing differentially private FL, and TEE solutions for FL, potentially mitigating privacy concerns. Furthermore, the present consideration of out-ofdomain data availability may also help alleviate these concerns.

[073] Experimental results show that: 1) Feddle substantially outperforms baselines (by over 10% on average) in both in-domain and out-of-domain data availability scenarios. 2) Feddle exhibits faster convergence and improved stability compared to baselines, showcasing its advantage in deployment. 3) Feddle demonstrates robustness against data heterogeneity or asynchronous communication, with its performance remaining relatively unaffected by strong heterogeneity and high delay in communication.

[074] An overview of the background and challenges associated with federated learning are now discussed, while briefly introducing relevant existing research.

[075] Centralized vs. Federated Learning: In centralized learning, a dataset© is collected and curated at a central storage location (centralized data regime), which is then used to train a model by minimizing the empirical loss, i.e., argmin^C©, co).

[076] In contrast, federated learning (FL) assumes that the data is fully distributed among / clients such that © = {©7} where j e {1, ...J} denotes the client index. A server orchestrates all clients to perform local training using their own data and aggregates their trained network weights to obtain a global model. This process enables the final global model to fit the population data distribution of all the clients p(©). The process is repeated for multiple rounds K. In particular, at the beginning of each round k, the server sends the latest global model cok to the clients for local training: Yj = 1 ...J, Mj = Mk; cok = argmin (1)

[077] After completing the local training, each client j sends its model update Acok = cok-cok back to the server. The server then merges the model updates {Acok}J=1 to obtain the next global model cok+1 based on a predefined aggregation method: = mCAco^, uk) (2) e. g.: MFedAvg(-) = <ok + ^A<ok. (3)

[078] Heterogeneous Data Distribution: As clients are often geographically distant or environmentally distinct from each other, their local data typically follows non-identical distributions, i.e., Bi,j e {1... / },p(;) #= pQ). Consequently, maximizing the data likelihoods of the tth client p(jh) and the jth client pQI;) during local training results in distinct posterior distributions p(jh) and pQI;), assuming consistent prior knowledge is applied across the clients. This implies that the model updates An..., A; also differ.

[079] The above analysis based on the Bayes’ rule can be verified with empirical results. To show that, CIFAR10 is distributed with respect to the Dirichlet distribution (denoted as Dir(-)) to 100 clients and conduct federated learning. It is found that when data is strongly heterogeneous, i.e. Dir(0.1): 1) Clients’ local trained models deviate from each other. 2) Clients disagree on the optimization direction, as some model updates point in a reversed direction of the true model update A: = Yj lyl / HAy, i.e., if e {1 ...J}, <0. If the true model update A aligns well with the gradient of the global model V: = V^(,), then conflicting local model update &jr can slow down the convergence as (A^V) <0. However, the true global model update A may not align with the gradient V, as it averages the model updates obtained from isolated datasets, whereas V averages the gradients over all the datasets. In practice, the server might sample a subset of clients to approximate the true model update. Therefore, although conflicting model updates are observed, it is challenging to determine which ones should be excluded or reversed. The phenomenon of conflicting model updates also implies that consistently assigning positive aggregation coefficients to all the clients is suboptimal, as their updates do not agree. However, many previous works have adopted this strategy.

[080] Asynchronous Communication: Equations 1 and 2 consider coordinating all clients simultaneously, which is impractical in real-world scenarios due to the communication limitations. To address this challenge, a stream of work proposes sampling a set of clients and merging their model updates once a certain number N of clients has reported their results, discarding delayed reports: k+1 = (<.....(4) where the subscripts ...jN indicate the earliest N clients reporting their results.

[081] This setup is considered synchronous communication, which has several drawbacks. Firstly, the server still needs to wait for the last reported client jN, including its downlink, local training, and uplink time. Secondly, many clients are initiated to run their local training, but their results are discarded due to communication delays, leading to excessive energy consumption. Additionally, some clients may have consistent inherent delays and struggle to report on time, causing the global model to learn a skewed data distribution. To address these issues, many works adopt asynchronous communication, where delayed reports can also be incorporated into the global model: k+1 = f{Akl, ...,AkN},kY (5) Here, the superscripts / c1... / cw respectively indicate the downlink rounds of clients when their local training is initialized (c.f. Equation 1), satisfying 1 <k1 ...kN <k. Figures 2A and 2B compare the asynchronous and synchronous mechanisms. However, asynchronous communication makes aggregating the global model more challenging, as delayed model updates may be outdated and worsen the optimization direction issue caused by heterogeneous data distribution.

[082] Method

[083] Motivation: It has been explained that many real applications involve hybrid data regimes, where either in-domain or out-of-domain data is available. When there is in-domain data availability, the server’s limited data may not be sufficient to train an optimal model compared to what can be achieved by leveraging the vast amount of distributed client data. On the other hand, out-of-domain data cannot be directly used to train a network applicable for processing distributed data. Furthermore, as discussed and demonstrated above, federated learning on distributed data is challenged by two key issues: the heterogeneity of data distribution among clients, which leads to conflicting model updates; and asynchronous communication, which can exacerbate this issue and cause overshooting in the optimization process.

[084] To address these challenges and unlock the potential of distributed data, the present techniques propose a novel approach that leverages server data in the aggregation step to identify the optimal merging coefficients of model updates reported by clients. By doing so, it is possible to effectively harness the strength of distributed data without overfitting on the server’s limited in-domain data, as the merging coefficients have small dimensions. Additionally, the present method demonstrates that out-of-domain data can be successfully utilized to guide the coefficient search, thereby providing a flexible solution for various data availability.

[085] Framework Architecture: The proposed framework, Federated Dual Learning (“Feddle”) is now introduced. First, an explanation of how to construct the model atlas is provided, which contains anchors ^...¾ that define the search space for the server to determine the corresponding merging coefficients cx... cM. Then, the objective function for the merging coefficients search is outlined in two distinct data availability scenarios: in-domain and out-of-domain data. To enhance the robustness of Feddle and improve its efficiency under weak signal scenario (e.g. out-of-domain data), a fallback mechanism is incorporated. An overview of the present framework is provided in Figure 3D, while the algorithmic details are for the server presented in Figure 4 and for the client / user devices in Figure 5.

[086] Model Atlas: In Feddle, a model atlas A is introduced that defines the optimization space of the server. The atlas consists of M anchors A = {am}"=1, each representing an optimization direction. By utilizing client model updates as anchor points, the server can optimize the global model in a subspace that has been explored by the clients, making it potentially more efficient. Notably, it is found that setting M to a relatively small value of 100 is sufficient to effectively update a large global model with approximately 107 parameters. This flexibility in choosing M allows the server to optimize the global model even when only limited data is available, mitigating the risk of overfitting.

[087] Addition and Removal of Anchors: When receiving a model update Acy from the jth client, it is added as an anchor to the atlas. Initially, when the atlas is not full, the next available index is assigned to the new anchor a|A|+1: = Any Once the atlas reaches its maximum size |A| = M, removal of an existing anchor is requested to accommodate a new one. Instead of using a simple first-in-first-out (FIFO) strategy, anchors are ranked based on their importance scores S = {sm}"=1 and remove the least important anchor am!, where sm, = min S. In Feddle, the absolute values are leveraged of the merging coefficients cr... cM found through coefficient search as importance scores Vm = 1 ...M,sm = \cm|, since they indicate the extent to which the global model has moved in each direction.

[088] Anchor Normalization: Since the model atlas A accepts all client updates without considering their delay and retains anchors based on their importance scores, the magnitudes of the anchors (i.e., model updates) will inevitably vary. This can lead to coefficients with different magnitudes, potentially causing optimization difficulties. To address this issue, before initiating coefficient search at each round, Feddle normalizes all anchors using the median of their norms: Vm = 1 ... |A|,am = medianQ^W ... | |aM|||) • (6) I I 11 Note that |A| is used instead of M as the upper bound for m, since Feddle can perform coefficient search even before the model atlas is fully populated.

[089] Search Objective: At each round k, the server searches for the optimal merging coefficients within the model atlas.

[090] In-Domain Data Availability: When in-domain data Ds ~D is available, the server can perform a direct search using the loss function consistent with local training: Ci ... C|A| = argmin(Ds,+ + ••• yA|), (7) where c = [c1;..., C|A|], In this work, the cross-entropy loss for multi-class classification tasks is used. After the search is completed, the global model is updated by: cok+1 = cok + c1a1 -I— c^a^. (8)

[091] Out-of-Domain Data Availability: When only out-of-domain data Dg + D is available, a surrogate loss function h is utilised to construct the optimization landscape for the coefficient search. To ensure that the search result found on the surrogate optimization landscape is beneficial for the federated population, a function h that satisfies the following is needed: (dh (D'^ / dc, d^^^ / dc} >0. (9)

[092] In practice, it is observed that this condition can be achieved even if D's and D are visually distinct. Since classification tasks are conducted, a simple parameterized surrogate loss function h$ is adopted, that replaces the classifier head a)he c fitted on D with a new classifier head fl . Denote the network w as consisting of two components: body and head, i.e., to = [cobo; co / ie], and similarly for anchors am = [amb0; amhe]. First train fl to classify the labels of Dg based on the embeddings extracted by cobo, and then search for the coefficients of the anchors. This objective can be formalized as: argmin h.#* (Dg,a>k,...), (10) c / 1,9(-) =+ ci«i,b0 (11) fl* = argmin h.#* (•). (12) e Although h$ ignores wbe and al he, ...a,|A|,he in Equation 12, it is found that the search results are a good indicator of the overall dimensions. Therefore, the full model is updated via ojk+1 = mk + c1a1 + ••• C|A|G|A|. The experiments show that this approach works well even when D contains grayscale images (e.g., Fashion-MNIST) and Dg has colorful images (e.g., ImageNet). It is noted that Feddle can potentially incorporate unsupervised learning technologies for the coefficient search by adopting the corresponding loss function for h. Then, Dg can be unlabeled data with more abundant resources.

[093] Fallback Mechanism: In practice, verifying the condition in Equation 9 may not be feasible, especially when d{(D,-) / dc is not accessible due to privacy concerns. To mitigate potential issue where Equation 9 is not likely satisfied during the coeffcient search, i.e. (dh(Dg,-) / dc, d{(D,-) / dc) <0, a fallback mechanism is introduced into Feddle to ensure robustness. To implement the fallback mechanism, we initialize the merging coefficients c(... using an existing FL method and add a regularization term to the search objective. The modified search objective becomes: argmin £ (Ds, ak + ...) + ^2™ (cm - c^)2, (13) c where A controls the regularization strength. The present techniques adopt FedBuff as the fallback method. However, Feddle can potentially leverage various FL methods as a fallback, which we leave for future exploration.

[094] Computational Efficiency: The optimization problem in Equation 8 requires loading the entire model u>k e IRd and all anchors ...a^i e IRd into memory simultaneously, which can be challenging when dealing with large models (d) and numerous anchors (|A|). To mitigate this issue, a technique to reduce the computational requirements is employed. During forward propagation (i.e. when computing Equation 8), the anchors are accumulated to the global model while stopping the gradient requirement: 6)' = stop_grad((jik + ^ + - cl^lal^|)- (14) Then, during backpropagation, we compute the gradient of the coefficients using: Vm = 1 ... |A|, d^dcm = {^,am). (15) For out-of-domain data availability, is replaced with h. By using Equations 14 and 15, the computation can be distributed across multiple nodes while storing the anchors and model in separate locations. This enables Feddle to support large models and model atlas.

[095] Figure 6 is a flowchart of example steps for updating, at a server, a global machine learning, ML, model using federated learning. The global ML model may have been pretrained using standard techniques before the method of Figure 6. The method comprises receiving a set of updated model parameters from a plurality of user devices, wherein each set of updated model parameters is obtained by local updating of a local instance of the global ML model by a user device (step S100); and adding the received sets of updated model parameters to an atlas that defines an optimisation space for the global ML model during the FL round (step S102). During each FL round, the method comprises: identifying optimal merging coefficients for merging the sets of updated model parameters in the atlas with model parameters of the global ML model (step S104) and updating the global ML model using the identified optimal merging coefficients and each set of updated model parameters in the atlas (step S106)

[096] As noted above, the atlas comprises a plurality of anchors. The step (S102) of adding the received sets of updated model parameters to an atlas may comprise: adding a set of updated model parameters to an anchor of the atlas.

[097] The step S102 of adding the received sets of updated model parameters to an atlas may comprise: determining, when a set of updated model parameters is received, whether an empty anchor exists in the atlas. The atlas may have a pre-defined number of anchors. Initially, at the start the federated learning, the atlas may be empty, i.e. all of the anchors may be empty. In this case, the atlas may be filled-up by all the incoming sets of updated model parameters. At the start of each FL round, the atlas may contain anywhere between all nonempty anchor to no non-empty anchors. In other words, if a single set of updated model parameters is received during an FL round, then this set is added to one anchor in the atlas, and this single anchor is used together with existing sets of updated model parameters in other anchors to update the global ML model. This is advantageous because it means that it is not necessary for a minimum number of updates to be received from user devices in order to perform an update of the global model during a FL round. Instead, all anchors in the atlas for determining the optimal merging coefficients and then using the optimal merging coefficient to create the updated global ML model at the end of the FL round.

[098] In one example, when an empty anchor is determined to exist, the method may comprise: adding the received set of updated model parameters to the empty anchor in the atlas. Thus, each set of updated model parameters received from a user device is added to the next available anchor in the atlas.

[099] Alternatively, when an empty anchor is determined not to exist, the method may comprise: calculating an importance score for the set of updated model parameters in each anchor; ranking the anchors based on the calculated importance scores; removing the set of updated model parameters in the anchor having the lowest ranked importance score, to form an empty anchor for the set updated model parameters to be added; and adding the set of updated model parameters to the created empty anchor in the atlas. That is, once the atlas reaches its maximum size (i.e. the anchors are all full), the content of an anchor is removed to accommodate a new set of updated model parameters. In other words, the set of updated model parameters from the lowest ranked anchor is cleared from the atlas. If multiple set of updated model parameters is received after all the anchors are full, a corresponding number of anchors having the lowest ranked importance score are cleared. Advantageously, the content of the atlas is optimised based on how important the received sets of updated model parameters are. The larger the importance score, the more useful the set of updated model parameters is for updating the global ML model.

[100] Calculating an importance score may comprise: identifying the optimal merging coefficients; and using the optimal merging coefficient for each set of updated model parameters as the importance score. Thus, once the atlas is full, the optimal merging coefficients may be determined for the anchors. The merging coefficients for each anchor (i.e. for the set of updated model parameters stored by each anchor) may serve as the importance score, since the merging coefficients indicate the extent to which the global ML model needs to be adjusted.

[101] The method may further comprise: normalising a magnitude of each parameter in each set of updated model parameters in the atlas prior to identifying the optimal merging coefficients. The presence of data heterogeneity and the asynchronous communication means that the updated model parameters received from user devices may vary in magnitude, which can lead to optimisation problems (such as over-fitting) in each FL round. Thus, advantageously, the present techniques normalise the magnitude of each parameter in each set of updated model parameters before identifying the optimal merging coefficients.

[102] The step S104 of identifying optimal merging coefficients may comprise: determining whether the sets of updated model parameters are obtained by local updating by user devices using in-domain local data or out-of-domain local data, wherein in-domain local data is in the same domain as data used to train the global ML model, and out-of-domain local data is in a different domain as data used to train the global ML model. The goal of federated learning is to train / update the global ML model by achieving some consensus on how the parameters received from all the user devices are to converge. The bigger the differences between the parameters received from the user devices and the current parameters of the global ML model, the more likely it is that the differences arise from the local data being different to server-side data used to train the global ML model originally.

[103] In a first case, when the sets of updated model parameters are obtained by local updating by user devices using in-domain local data, identifying optimal merging coefficients may comprise: identifying, using any suitable loss function, e.g. a cross-entropy loss, the optimal merging coefficients. In this case, the server can perform a direct search for the optimal merging coefficients using a loss function that is consistent with training performed by the user devices.

[104] In a second case, when the sets of updated model parameters are obtained by local updating by user devices using out-of-domain local data, identifying optimal merging coefficients may comprise: generating a new classifier head to replace a classifier head in the global ML model; and identifying optimal merging coefficients using the new classifier head. Identifying optimal merging coefficients may comprise training the new classifier head to minimise the loss between labels of the training data set and labels generated using the global body of the global ML model and then identifying optimal merging coefficients for merging the global body of the global ML model with the sets of updated body parameters. This is explained in more detail in the in-domain and out-of-domain availability sections above.

[105] In a third case, when the sets of updated model parameters are obtained by local updating by user devices using both in-domain local data and out-of-domain local, identifying optimal merging coefficients may comprise: identifying, using a cross-entropy loss and the sets of updated model parameters obtained using in-domain local data, the optimal merging coefficients for merging the updated model parameters using in-domain local data with the global ML model; generating a new classifier head to replace a classifier head in the global ML model; and identifying, for the sets of updated model parameters obtained using out-ofdomain local data, optimal merging coefficients using the new classifier head.

[106] Receiving, at step S100, sets of updated model parameters from a plurality of user devices may comprise: receiving a set of updated model parameters from at least some user devices at any time. That is, the present techniques utilise asynchronous communication and updates received from user devices do not fail. If an update is received just after the server has already performed an update of the global ML model and shared the new global ML model with the user devices, even though the update is performed with respect of an older version of the global ML model, the update may be added to the atlas.

[107] Identifying optimal merging coefficients at step S104 may comprise: identifying optimal merging coefficients using the atlas at the end of a pre-defined time frame from the global ML model being sent to the user devices (e.g. after a fixed time has elapsed from the start of an FL round). . As noted above, whatever is in the atlas at the end of the time frame is used to perform the update of the global ML model. Any updates received after this time frame may be added to the atlas for the new / next FL round instead of simply being rejected.

[108] The method may further comprise: transmitting, after the updating, the updated global ML model to all user devices of the plurality of user devices, wherein the updated global ML model forms a new local instance of the global ML model on each user device.

[109] Figure 7 is a block diagram of a system for updating a global ML model using federated learning.

[110] The system comprises a plurality of client / user devices 200. Only a single user device 200 is shown here for the sake of simplicity but it will be understood that the system may comprise hundreds, or hundreds of thousands of user devices. Each user device comprises at least one processor 202 coupled to memory 204 for: receiving, at the start of a federated learning, FL, round, a local instance of the global ML model 206 for local training from a server; training the local instance of the global ML model using local, client data 208 stored on the client device; and transmitting, after the training, a set of updated model parameters for the trained local instance of the global model to the server.

[111] The system comprises a server 100 for updating a machine learning, ML, model 106 using federated learning. The server 100 is communicatively coupled to the user devices 200. The server comprises: storage storing a global ML model 106 and a model atlas 108; and at least one processor 102 coupled to memory 104, for performing the methods described herein. The server may store server-side training data 110.

[112] The server 100 may comprise at least one processor 102 coupled to memory 104 and arranged for implementing the methods described herein. The memory 104 may store instructions that, when executed by the at least one processor 102 individually or collectively, cause the at least one processor to perform the methods described herein.

[113] Experiments

[114] Datasets, models, baseline methods: Experiments are conducted on image classification tasks using four datasets: CIFAR-10 / 100, Street View House Numbers (SVHN), and Fashion-MNIST. A convolutional neural network (CNN) and ResNet-18 are employed, where ResNet-18 is pretrained on ImageNet, and full fine-tuning is evaluated. The present method Feddle is compared with classical synchronous FL approaches FedAvg, FedProx and competitive asynchronous FL approaches FedAsync, FedBuff, and CA2FL. For in-domain data availability scenario, a baseline called Center is evaluated, which trains the model solely using the server data.

[115] Implementation Details: A scenario with 500 clients, and 200 communication rounds, is defined. At each round, 10 clients are sampled. Clients have heterogeneous data characteristics in terms of the class label distribution and samples size per class. Specifically, two levels of data heterogeneity are simulated by partitioning the data using the Dirichlet distribution with parameters Dir(0.1) and Dir(0.3). Additionally, the delay for each client is modelled using a half-normal distribution, denoted as N, with standard deviation of 5 and 20. The experiments are repeated 3 times, and the mean and standard deviation are reported.

[116] Results: First, the results for the scenario when in-domain data is available on the serverside is presented, assuming a small dataset of 1000 examples. Then an alternative scenario is considered where no such in-domain dataset is available, but the server has access to an out-of-domain dataset instead.

[117] In-Domain Data Availability. For a fair comparison with Feddle, the server-side data is also used as a validation set for the baseline FL methods, thereby preventing updates to the global model if the loss on this dataset increases after each aggregation step. This validation check serves as a quality control mechanism and has practical significance.

[118] Figure 8 is a table showing the results of experiments to compare in-domain data availability. It is observed that Feddle consistently outperforms all the baseline methods with a clear margin, except for CIFAR-100 and Dir(0.3), N(5) where CA2FL achieves slightly better results than Feddle. Overall, the baselines perform worse in scenarios with strong heterogeneity Dir(0.1) and high delay N(20) compared to the simpler scenario Dir(0.3) and N(5). In contrast, Feddle’s performance is less affected by heterogeneity or delay, leading to an outstanding accuracy even in a complex scenario. Specifically, it is noticed that the SVHN dataset is inherently imbalanced, which exacerbates the heterogeneity caused by sampling. As a result, multiple baselines fail to converge when trained from scratch on CNN (accuracy ~ 10%), whereas Feddle consistently achieve more than 80% accuracy across simple and complex scenarios. These results highlight the crucial role that server-side data guidance can play when learning from decentralized data on edge devices, which often face challenges such as high heterogeneity and unpredictable long delays.

[119] Additionally, 1000 server-side data points account for only 1 / 50 of the decentralized training data for CIFAR10 / 100, and less than 1 / 50 for SVHN and Fashion-MNIST. However, in relatively complex scenarios, baseline FL methods often fail to achieve better performance using a large amount of decentralized data compared to Center, which is trained solely on server data. Notably, Feddle can always achieve significantly higher performance than Center, demonstrating that the present method can effectively leverage the value of decentralized data under the guidance of server-side data. Moreover, a closer inspection of the convergence plots reveals that Feddle converges faster than the baseline methods, showcasing its advantage of early deployment (see Figure 9). Figure 9 shows convergence plots for indomain data availability using ResNet18 and CIFAR-10.

[120] Out-of-Domain Data Availability: In this case, Feddle leverages a subset of ImageNet to guide the coefficient search, while baseline FL methods aggregate model updates without any validation checks. Figure 11 is a table showing comparisons for out-of-domain data availability using ResNet18. The experiments are based on Dir(0.1), Dir(0.3), N(5) and N(20). The best performance is shown in bold. Since a ResNet18 pretrained on ImageNet is adapted, the comparison between Feddle and baselines is fair, as they have access to the same data information.

[121] As per Figure 11, Feddle achieves the best performance in most settings. Especially, in complex scenarios with strong heterogeneity and high delay, Feddle outperforms the baselines by a clear margin, indicating that searching for model merging coefficients is also feasible and effective without relying on in-domain data. Notably, such search remains reliable even when decentralized data (e.g., Fashion-MNIST) and server-side data (e.g., ImageNet) are visually distinct. Additionally, it is observed that without validation checks CA2FL and FedBuff generally achieve lower accuracy, while FedAvg, FedProx and FedAsync sometimes perform better (c.f. Figure 8). The reason for the latter case is that a validation check can reject multiple rounds, reducing the effective number of rounds and thereby leading to slower convergence. However, baselines cannot compete with Feddle, regardless of whether indomain or out-of-domain data is available. Furthermore, a larger standard deviation is observed in the results compared with Figure 8 which may not be desirable in deployment. A closer inspection of the results shows that global model performance oscillates significantly during training without validation check (see Figure 10, which shows convergence plots for out-of-domain data availability using ResNet18 and CIFAR-10). Nevertheless, Feddle exhibits faster and comparatively more stable convergence.

[122] Ablation Studies: The ablation studies on atlas size, validation set size (in-domain data availability) and Feddle components are presented.

[123] The Impact of Atlas Size. Figures 13A and 13B show the impact of atlas size on performance when using, respectively, in-domain server-side data, and out-of-domain serverside data. Experiments are performed using a CNN and the Cl FAR-10 dataset. It is observed that Feddle can work with an atlas size as small as 50, indicating that model updates reported by clients can efficiently compress the optimization space, allowing the server to conduct coefficient search in a low-rank space. Additionally, it is found that for in-domain server-side data, performance is barely affected by growing atlas size, whereas for out-of-domain data, performance drops drastically. It is hypothesized that for the latter case, the optimization signal is weak. Therefore, the constrained optimization space serves as a regularizer that benefits the coefficient search.

[124] The Impact of Validation Dataset Size. Figures 14A and 14B show the impact of the validation dataset size (in-domain server-side data) on performance when using, respectively, Dir(0.1), N(20), and Dir(0.3), N(5). Experiments are performed using a ResNet and the Cl FAR-10 dataset. The data shows that Feddle can outperform centralized training and FL baselines across varying validation dataset (in-domain server-side data) sizes. When limited server-side data is available (e.g. 500 data points or 1 / 100 of the decentralized training data), Center performs worse than FL baselines, but Feddle can leverage server-side data to guide the learning of decentralized data and achieve better performance. Conversely, when serverside data is abundant (e.g 4000 data points or approximately 1 / 10 decentralized training data), Center can outperform all FL baselines. However, Feddle can simultaneously leverage both centralized and decentralized data to achieve even better performance.

[125] The Analysis of Feddle Components. Figure 12 is a table showing the analysis of Feddle components for in-domain and out-of-domain data availability using ResNet18 and CIFAR-10 dataset with the scenario Dir(0.1), N(20). The table demonstrates the effectiveness of Feddle’s components, highlighting their crucial roles in achieving superior performance. Notably, it is found the fallback mechanism is essential for handling out-of-domain data. It is hypothesized that the surrogate loss for out-of-domain data may exhibit multiple local minima, requiring a good initialization and some form of regularization for the convergence.

[126] The present techniques target on hybrid data regimes in realistic use cases and explore the value of decentralized data within these regimes. Building upon existing federated learning approaches that investigate the challenges of learning from decentralized data, the present techniques propose a federated dual learning approach. The proposed method Feddle provides a flexible solution for practical applications under various scenarios, as it can be applied whether the server data is in-domain or out-of-domain with respect to the clients’ data. Experimental results demonstrate that Feddle achieves significantly better performance compared to existing methods, highlighting its benefits fortraining networks with decentralized data.

[127] References • Cl FAR-10 / 100 • Street View House Numbers (SVHN) • Fashion-MNIST • ResNet-18 • ImageNet • FedAvg • FedProx • FedAsync • FedBuff • CA2FL • Half-normal distribution

[128] Those skilled in the art will appreciate that while the foregoing has described what is considered to be the best mode and where appropriate other modes of performing present techniques, the present techniques should not be limited to the specific configurations and methods disclosed in this description of the preferred embodiment. Those skilled in the art will recognise that present techniques have a broad range of applications, and that the embodiments may take a wide range of modifications without departing from any inventive concept as defined in the appended claims.

Claims

1. A computer-implemented method for updating, at a server, a global machine learning, ML, model using federated learning, the method comprising:receiving sets of updated model parameters from a plurality of user devices, wherein each set of updated model parameters is obtained from a user device after local updating of a local instance of the global ML model by the user device;adding the received sets of updated model parameters to an atlas that defines an optimisation space for the global ML model;during each federated learning, FL, round:identifying optimal merging coefficients for merging the sets of updated model parameters in the atlas with model parameters of the global ML model; andupdating the global ML model using the identified optimal merging coefficients and each set of updated model parameters in the atlas.

2. The method as claimed in claim 1 wherein the atlas comprises a plurality of anchors, and wherein adding the received sets of updated model parameters to an atlas comprises:adding each set of updated model parameters to a separate anchor of the atlas.

3. The method as claimed in claim 2 wherein adding each set of the received sets of updated model parameters to an atlas comprises:determining, after receiving the set of updated model parameters to be added, whether an empty anchor exists in the atlas.

4. The method as claimed in claim 3 wherein when an empty anchor is determined to exist, the method comprises:adding the received set of updated model parameters to the empty anchor in the atlas.

5. The method as claimed in claim 3 wherein when an empty anchor is determined not to exist, the method comprises:calculating an importance score for each anchor in which there is a set of updated model parameters;ranking the anchors based on the calculated importance scores;removing the set of updated model parameters in the anchor having the lowest ranked importance score, to form an empty anchor for the set of updated model parameters to be added; andadding the set of updated model parameters to the created empty anchor in the atlas.

6. The method as claimed in claim 5 whereinidentifying the optimal merging coefficients comprises identifying an optimal merging coefficient for each set of updated model parameters; andcalculating an importance score comprises using a magnitude of the identified optimal merging coefficient for each set of updated model parameters as the importance score for each anchor.

7. The method as claimed in any preceding claim further comprising:normalising a magnitude of each parameter in each set of updated model parameters in the atlas prior to identifying the optimal merging coefficients.

8. The method as claimed in any preceding claim wherein identifying optimal merging coefficients comprises:determining whether the sets of updated model parameters are obtained by local updating by user devices using in-domain local data or out-of-domain local data, wherein indomain local data is in the same domain as data used to train the global ML model, and out-of-domain local data is in a different domain as data used to train the global ML model.

9. The method as claimed in claim 8 wherein when the sets of updated model parameters are obtained by local updating by user devices using in-domain local data, identifying optimal merging coefficients comprises:identifying, using a cross-entropy loss, the optimal merging coefficients.

10. The method as claimed in claim 8 wherein when the sets of updated model parameters are obtained by local updating by user devices using out-of-domain local data, identifying optimal merging coefficients comprises:generating a new classifier head to replace a classifier head in the global ML model; and identifying optimal merging coefficients using the new classifier head.

11. The method as claimed in claim 8 wherein when the sets of updated model parameters are obtained by local updating by user devices using in-domain local data and out-of-domain local, identifying optimal merging coefficients comprises:identifying, using a cross-entropy loss and the sets of updated model parameters obtained using in-domain local data, the optimal merging coefficients for merging the updated model parameters obtained using in-domain local data with the global ML model;generating a new classifier head to replace a classifier head in the global ML model; and identifying, for the sets of updated model parameters obtained using out-of-domain local data, optimal merging coefficients using the new classifier head.

12. The method as claimed in claim 10 or claim 11 wherein identifying optimal merging coefficients using the new classifier head comprises:training the new classifier head to minimise loss between labels in a training dataset and labels generated using a global body of the global ML model; andidentifying optimal merging coefficients for merging the global body of the global ML model with the sets of updated body parameters from the sets of updated model parameters obtained using out-of-domain local data.

13. The method as claimed in any preceding claim wherein receiving sets of updated model parameters from a plurality of user devices comprises:receiving sets of updated model parameters from at least some user devices at any time.

14. The method as claimed in any preceding claim further comprising:transmitting, after the updating, the updated global ML model to all user devices of the plurality of user devices, wherein the updated global ML model forms a new local instance of the global ML model on each user device.

15. A server for updating a global machine learning, ML, model using federated learning, the server comprising:storage storing a global ML model and a model atlas; andat least one processor coupled to memory, configured for:receiving sets of updated model parameters from a plurality of user devices, wherein each set of updated model parameters is obtained from a user device after local updating of a local instance of the global ML model by the user device;adding the received sets of updated model parameters to an atlas that defines an optimisation space for the global ML model;during each federated learning, FL, round:identifying optimal merging coefficients for merging the sets of updated model parameters in the atlas with model parameters of the global ML model; andupdating the global ML model using the identified optimal merging coefficients and each set of updated model parameters in the atlas.

16. A computer-implemented method for updating, at a client device, a global machine learning, ML, model using federated learning, the method comprising:receiving, at the start of a federated learning, FL, round, a local instance of the global ML model for local training from a server;training the local instance of the global ML model using client data stored on the client device; andtransmitting, after the training, a set of updated model parameters for the trained local instance of the global model to the server.

17. A system for updating a global machine learning, ML, model using federated learning, the system comprising:a plurality of client devices; anda server comprising:storage storing a global ML model and a model atlas; andat least one processor coupled to memory, configured for:receiving sets of updated model parameters from the plurality of user devices, wherein each set of updated model parameters is obtained from a user device after local updating of a local instance of the global ML model by the user device;adding the received sets of updated model parameters to an atlas that defines an optimisation space for the global ML model;during each federated learning, FL, round:identifying optimal merging coefficients for merging the sets of updated model parameters in the atlas with model parameters of the global ML model; andupdating the global ML model using the identified optimal merging coefficients and each set of updated model parameters in the atlas.

18. A computer-readable storage medium comprising instructions which, when executed by a processor, causes the processor to carry out the method of any of claims 1 to 14 or 16.A