A Data-Free Approach to Mitigate Catastrophic Forgetting in Federated Class Incremental Learning for Vision Tasks

Summary

In this paper, authors propose a new approach to perform class-incremental learning in federated setting. Their approach uses a generative model trained at the server side which generates synthetic images to be used as a replacement for data corresponding to old classes. The authors claim through empirical results that their approach outperform all the earlier approaches for this problem.

Strengths

This paper clearly articulates the class incremental training in a federated learning setting and the related challenges. The paper also clearly explains different loss functions used for training the generative model and the client training paradigms used in the proposed approach. Ablation study is also performed to break down the gains into different constituents of the approach.

Weaknesses

On page 3, authors mention that the main difference between FedCIL and their approach is that generative model in the proposed approach is trained in a data free manner which can reduce client's training time and computation. It's not clear how does this difference leads to such better performance in the experimental results. It will be nice to have some discussion and experiments to explain. As mentioned on page 4, line 177, the generative model produces samples resembling the original training inputs and given that this model is transmitted to all the clients, why this is not a privacy issue? It will be good to analyze any potential privacy leakage through the shared generative model. It's not clear the SuperImageNet dataset claimed by the authors, is it just a regrouping of the ImageNet Dataset or something more substantial. In Fig. 5, it's quite surprising to see the such a poor performance of FedCIL compared to FedAvg and FedProx which are not even designed for this problem. There is not much discussion in the paper on this. Specifically, are these results over one run or multiple runs? What hyper parameter thing has been performed for these approaches. In Fig. 5, performance of MFCL is falling the most as we go from CIFAR-100 to tinyImageNet to SuperImageNet although the number of samples per task is increasing. It will be good to understand why is this observed?

Questions

Please see above.

Rating

5: Borderline accept: Technically solid paper where reasons to accept outweigh reasons to reject, e.g., limited evaluation. Please use sparingly.

Confidence

4: You are confident in your assessment, but not absolutely certain. It is unlikely, but not impossible, that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work.

Soundness

3 good

Presentation

4 excellent

Contribution

3 good

Limitations

NA

Summary

This paper introduces a framework for federated class incremental learning, which employs a generative model trained at the server. This model is then utilized by the client to generate samples from previous distributions to mitigate catastrophic forgetting.

Strengths

This paper addresses the challenging problem of CIL (Class Incremental Learning) within the FL (Federated Learning) framework. It introduces a novel approach of data-free generative model training in the FL framework. Furthermore, the paper proposes a new benchmark dataset for FCIL called SuperImageNet. The effectiveness of the proposed method is demonstrated through extensive experiments.

Weaknesses

This paper uses small-scale model and generative model. It is uncertain how the communication cost and local computational cost will be affected when scaling up and using a generative model.

Questions

1) Is it practical for all clients to share same task transitions at a specific point in time? 2) If storing data locally becomes an issue, the local model update should be performed in a single iteration, and the samples should be discarded afterward. Allowing multiple iterations implies that data has already been stored locally, thus raising privacy concerns associated with data storage. If limited memory resources are the problem, it is understandable. However, there is a concern about whether the generative model will maintain affordable computational complexity as the scale increases. 3) If the server maliciously trains the data-free generative model using a specific local model instead of the aggregated model, wouldn't this lead to privacy issues? 4) Is the L_KD in Eq. (8) and Eq. (9) same with the L_KL in Table 5? 5) At each task boundary, how did you validate the trained generative model?

Rating

5: Borderline accept: Technically solid paper where reasons to accept outweigh reasons to reject, e.g., limited evaluation. Please use sparingly.

Confidence

4: You are confident in your assessment, but not absolutely certain. It is unlikely, but not impossible, that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work.

Soundness

3 good

Presentation

3 good

Contribution

3 good

Limitations

I have some concerns about the communication cost and local computational cost that may arise when using a generative model at scale. It remains uncertain whether these costs will be negligible still.

Summary

The work proposes using a server-learned generator for synthetic data replay for federated Class-IL. The method saves client-level compute while preserving data-privacy. The authors show their method outperforms existing methods on 2 existing benchmarks, plus a proposed larger-scale ImageNet benchmark protocol.

Strengths

1) I am already familiar with this setting, but I feel that the authors did a good job at selling the problem-setting to me. While potentially space inefficient, table 1 is very concise and convincing. 2) Moving from multiple client generators -> server generator is very justified, as it will save client compute time. Also, the generator does not need to be communicated from the client to the server, only from the server to the client. 3) The proposed approach does have significantly better performance, especially on the first two datasets. 4) Thank you for the transparency on training costs and server overhead. I do not think the large server overhead is a big deal - since the client costs are minimally affected in T = 1 compared to FedLwF.

Weaknesses

1) The novelty seems to be in more of a high-level idea combination of [45] and federated learning. I am not sure the method is truly impactful from a novelty perspective. 2) SuperImageNet is a protocol benchmark, not a "new benchmark dataset". However, I do appreciate the protocol and agree it is better than CIFAR-100 and TinyImageNet. 3) Overall, the performance is very weak of all methods. I wonder if the impact might be increased with a more realistic setting where past class examples may re-appear in future tasks. Could also consider a small replay buffer and/or a pre-trained model. 4) Often, federated learning papers include some type of theoretical analysis on, for example, convergence.

Questions

a) What specifically would you state are your method contributions compared to a federated variant of [45] and similar approaches? b) How do you think your method would perform in more realistic federated CL settings where classes are not Overall, I am worried about the contributed novelty and impact for a venue such as NeurIPS. However, I do think the paper is sound, and in-line with similar works accepted to recent high-tier conferences (e.g., [A]). I am very borderline, but would rather lean towards the accept side. A. Qi, Daiqing, Handong Zhao, and Sheng Li. "Better generative replay for continual federated learning." arXiv preprint arXiv:2302.13001 (2023). Other -> I am not sure that data-free image generation actually protects data-privacy concerns, since you are creating synthetic training data, but, since this line of work is already established, I do not feel the authors need to further justify it. -> Line 48, might be missing a space between "replay" and "[42]"

Rating

6: Weak Accept: Technically solid, moderate-to-high impact paper, with no major concerns with respect to evaluation, resources, reproducibility, ethical considerations.

Confidence

5: You are absolutely certain about your assessment. You are very familiar with the related work and checked the math/other details carefully.

Soundness

3 good

Presentation

3 good

Contribution

2 fair

Limitations

The discussion on limitations is concise and complete.

Summary

This work introduces MFCL, a method to primarily alleviate the catastrophic forgetting problem that arises in (more realistic) FL settings framed under the continual learning paradigm. In MFCL, the model is split into a generator (only trained on the server side) and a discriminator (only trained by clients). The former is data-free generative model that is trained to output synthetic samples suitable for the task(s) the discriminator is trained (in federation) to perform. This generator is also used by the clients to inject some synthetic training examples into their own local training stages. This component helps counteracting the forgetting problem. The empirical evaluation suggest that MFCL is far superior to other methods.

Strengths

The main strength of this paper is that it studies a far more realistic setting in which FL is used in practice for cross-device settings: clients come and go; data in the clients changes over time (more is added, some might be deleted); and, there is no centralised dataset available on the server. To this problem, MFCL proposes a solution that, although borrowing components and ideas from existing works, have been adapted to the FL setting and they work well. Other strengths that I have identified: * The generative model is of a reasonable size (<1M params if my understanding is correct when looking into Table 1 in the Appendix) * The Authors proposed SuperImageNet dataset.

Weaknesses

The main weaknesses I see in this work are related to lack of clarity in some important point: * In my view, folks in the FL community might not be familiar with the concept of "task" (common in the CL literature). This means that Sec 3.2 and other parts before might not be so clear. Later in Sec 4 (in line 261 onwards) a clear example of what a _task_ is is presented. Maybe it's worth giving an informal definition earlier? * The main results (i.e. Figure 5) are not super clear how to interpret. What does it mean "shows the accuracy of the model on the observed classes so far" (line 315)? Is the plot generated at `t=10` (i.e. after all tasks are completed)? * Following the comment above: wouldn't it be more informative to have "task" on the x-axis and show how test accuracy (or forgetting) changes as time passes? Presenting the results in such way are more common in some recent CL works I've been reading [1] (see for instance Figures 3,4,5 -- no, I'm not an author :) ) * Figure 3: I think it could be improved adding more details and nomenclature introduced in the text otherwise, what toes the right hand side of Fig3.a tell us that we don't know about all generative training schemes out there? Also, is the "aggregate" green box in Fig3.a outputting the discriminator (yellow rhomboid on the right)? (I think so, so how about connecting them?) [1] https://arxiv.org/abs/2303.11165

Questions

In addition to the questions I ask in the _Weaknesses_ section, I have a few more: * Maybe include in the Appendix some additional information about the experimental setup: it seems you used PyTorch, as for FL framework I see there are some utility functions from Flower but for the rest I looks you implemented a custom for loop. * Why not going a step further with `SuperImageNet` and also fix the number of clients it can be divided into? In FL papers are often hard to compare because people use datasets (synthetic ones specially) in vastly different ways. In my opinion if you were to fix how many partitions it contains, it would help easing the reproducibility problem of FL and ensure subsequent papers that use `SyperImageNet` do so under a common setup. What do you think? * The role of injecting synthetic images during training (on the client side) could be seen as some form of "alignment" mechanism. This has been presented before in FL [1]. Maybe the Authors could comment whether calling this "alignment" is correct and put it in context with other works? (I only suggested the one that comes to mind immediately, but there are more) * (very minor style comment) wouldn't It be better to have only full page wide figures/tables (like Fig3) instead of half-page ones (like Tab2,3 and Fig 4) ? [1] https://arxiv.org/abs/2202.05963

Rating

6: Weak Accept: Technically solid, moderate-to-high impact paper, with no major concerns with respect to evaluation, resources, reproducibility, ethical considerations.

Confidence

4: You are confident in your assessment, but not absolutely certain. It is unlikely, but not impossible, that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work.

Soundness

3 good

Presentation

2 fair

Contribution

3 good

Limitations

There are a few limitations that come to mind after reading this paper: * How does this method extend to other domains beyond image classification? or image-based problems in general? (I'm inclined to suggest the title of this paper to include the "image" or "vision" keyword) * In the Discussion, the Authors briefly talk about the privacy implications. I agree that synthetic images do not "resemble any specific training example" but this doesn't have to hold to have some privacy leak. As stated in line 61, the generative model "does not cause any extra data leakage from them [the clients]". But there is a data leak on the discriminator part (just like any other FL method that doesn't apply Differentiable Privacy or similar). Could the Authors comment what would be the implications of adding DP to the discriminator on the client side?

Updated rating

I have updated my rating based on the responses above by authors. Thanks!

Reviewer p34V response to rebuttal

Due to the hard work by the authors in answering my questions (including the new experiments), I have increased my score to weak accept. I still have some minor reservations on novelty/impact, but the paper is very sound with clear contributions and thus I recommend its acceptance.

Thanks Area Chair Bkb2 and reviewer NkkA

We appreciate the AC for following up on our rebuttal and thank the reviewer for their helpful reviews. However, since we have not received any response from reviewer NkkA on our rebuttal, we are not sure which of their concerns remain and require additional clarification. It would be greatly appreciated if the reviewer could kindly let us know if our rebuttal has properly addressed their concern. Here, we provide a summary of our rebuttal; 1. **Communication and computation costs at scale**. The extra cost of CL methods is to help clients mitigate forgetting. In our rebuttal, we explained generative models (as we use in our work) scale better than memory-based techniques since (1) the generative model's size is independent of the number of tasks and (2) clients can delete the model after training. In addition, we provided a few ways to reduce the extra overhead in communication and computation. 2. **Privacy concerns associated with data storage**. Data retention policies, in general, are concerned with the purpose and the duration of storing personal data. For example, one of the principles of GDPR (General Data Protection Regulation) requires data to be removed after it is processed for its stated purpose. The permitted storage duration can vary based on the data type and business. However, this duration can be long enough to train the local model for a few iterations. 3. **Malicious server**. A common solution to the mentioned malicious server attack is secure aggregation. We designed MFCL to be compatible with secure aggregation and other common defense mechanisms. The key is that MFCL does not require access to individual client updates and uses the aggregated model for training. Therefore, training the generative model is still viable after incorporating these defense mechanisms. 4. **Sharing the same task transitions**. We share this property with recent federated continual learning papers (e.g., FedCIL[1] @ ICLR'23) and follow the standard practice in centralized continual learning to measure the effectiveness of our approach. We believe this setting is closer to practice than conventional FL studies, where the training data does not change. In addition, clients and the server can form an agreement on the transition. [1] D. Qi, et al. "Better generative replay for continual federated learning." ICLR, 2023.

Thank the reviewers for their insightful feedback

We are grateful to all the reviewers for reading our paper and for their valuable comments/questions, which helped us improve our manuscript. We thank Reviewer 4Enn for finding our setting more realistic, identifying our effort in addressing the challenges of adapting continual learning for FL, and highlighting the size of the generative model and SuperImageNet dataset as our strengths; Reviewer p34V for praising our design choices, superior performance, clarity, and writing; Reviewer NkkA for complementing the novelty of our approach, solving a challenging problem, introducing SuperImageNet, and providing extensive empirical results; Reviewer zVmx for praising our empirical results and clarity of writing. We have provided detailed responses to comments/questions and will incorporate their suggestion in our final manuscript. In the following, we would also like to explain more about the **Privacy** in our method. 1- Training the generative model is already possible for the server and participants in the existing FL frameworks, such as FedAvg, because this training only requires access to the global model. Therefore, sharing the generative model in our method does not introduce additional privacy issues. 2- In our method, the server only requires the global weights, not the individual updates. Therefore, our method is compatible with the existing defense mechanisms that protect the privacy of participants' updates. 3- Our method is more private than the state-of-the-art solutions for federated class incremental learning because it does not require sharing perturbed training data or training the generative model on the local sensitive data. Thank you again for reviewing our paper and for the insightful comments.