Launch HN: Flower (YC W23) – Train AI models on distributed or sensitive data
Flower lets you train ML models on data that is distributed across many user devices or “silos” (separate data sources) without having to move the data. This approach is called federated learning.
A silo can be anything from a single user device to the data of an entire organization. For example, your smartphone keyboard suggestions and auto-corrections can be driven by a personalized ML model learned from your own private keyboard data, as well as data from other smartphone users, without the data being transferred from anyone’s device.
Most of the famous AI breakthroughs—from ChatGPT and Google Translate to DALL·E and Stable Diffusion—were trained with public data from the web. When the data is all public, you can collect it in a central place for training. This “move the data to the computation” approach fails when the data is sensitive or distributed across organizational silos and user devices.
Many important use cases are affected by this limitation:
* Generative AI: Many scenarios require sensitive data that users or organizations are reluctant to upload to the cloud. For example, users might want to put themselves and friends into AI-generated images, but they don't want to upload and share all their photos.
* Healthcare: We could potentially train cancer detection models better than any doctor, but no single organization has enough data.
* Finance: Preventing financial fraud is hard because individual banks are subject to data regulations, and in isolation, they don't have enough fraud cases to train good models.
* Automotive: Autonomous driving would be awesome, but individual car makers struggle to gather the data to cover the long tail of possible edge cases.
* Personal computing: Users don't want certain kinds of data to be stored in the cloud, hence the recent success of privacy-enhancing alternatives like the Signal messenger or the Brave browser. Federated methods open the door to using sensitive data from personal devices while maintaining user privacy.
* Foundation models: These get better with more data, and more diverse data, to train them on. But again, most data is sensitive and thus can't be incorporated, even though these models continue to grow bigger and need more information.
Each of us has worked on ML projects in various settings, (e.g., corporate environments, open-source projects, research labs). We’ve worked on AI use cases for companies like Samsung, Microsoft, Porsche, and Mercedes-Benz. One of our biggest challenges was getting the data to train AI while being compliant with regulations or company policies. Sometimes this was due to legal or organizational restrictions; other times, it was difficulties in physically moving large quantities of data or natural concerns over user privacy. We realized issues of this kind were making it too difficult for many ML projects to get off the ground, especially in domains like healthcare and finance.
Federated learning offers an alternative — it doesn't require moving data in order to train models on it, and so has the potential to overcome many barriers for ML projects.
In early 2020, we began developing the open-source Flower framework to simplify federated learning and make it user-friendly. Last year, we experienced a surge in Flower's adoption am...
70 comments
[ 4.2 ms ] story [ 144 ms ] threadFor example for your cancer use case, you have to convince multiple hospitals to feed the system labels and this is a very very tall ask.
For healthcare it’s also not clear how to get a regulatory clearance if you can’t actually test the performance of the federated deployments.
So while federated learning solves some problems generated by an unwillingness to share data, it doesn’t solve all of them. Describe the use cases of your product carefully.
https://arxiv.org/abs/2207.01975
https://arxiv.org/abs/2204.02804
For those that are interested: The best work currently I've seen on training very large models under federated learning, that also makes very realistic assumptions about the likely underlying participating hardware, is this: https://arxiv.org/abs/2206.11239 -- although I expect more in this direction to come soon.
It's also unclear how useful full scientific articles are, Microsoft/PubMedBERT interestingly showed PMC abstracts was better than full text.
I've been working on a project for over a year that uses flower to train cv models on medical data.
One aspect that we see being brought up again and again is how we can prove to our clients that no unnecessary data is being shared over the network.
Do you have any tips on solving that particular problem? I.e. proving that no data apart from model weights are being transferred to the centralized server?
Thanks a lot for the project.
edit: Just to clarify I am aware of differential privacy, I'm talking more on a "how to convince a medical institution that we are not sending its images over the network" level.
For this reason, one must assume that the model form is known to the adversary.
With this, the question becomes: is it possible to reconstruct training data from a trained model? We already know that, at least for some image models, the answer to that question is "yes": https://arxiv.org/pdf/2301.13188.pdf
One approach to increase the transparency on the client side (and build trust with the organization where the Flower clien is deployed) is to integrate a review step that asks the someone to confirm the update that gets send back to the server.
On top of that, you should definitely use differential privacy. To quote Andrew Trask here: "friends don't let friends use FL without DP". Other approaches like Secure Aggregation can also help, depending on what kind of exposure your clients are concerned about.
My general take is that the best way to solve for transparency and trust is to tackle it on multiple layers of the stack.
I'm trying to apply federated learning to the medical domain too and I'm trying to define the best "stack" that guarantees privacy and compliance with regulations like the GDPR
Congrats on the launch Flower team!
I'll be looking into secure aggregation as I'm not fully aware of how it works. As of now we rely on differential privacy only.
Thanks!
https://arxiv.org/abs/2105.06413 https://openfl.readthedocs.io/en/latest/index.html https://gramineproject.io/
This is the official press release for those who are interesed: https://www.intel.com/content/www/us/en/newsroom/news/transi...
More broadly, in regards too your comment -- our current SA support does not require hardware support, which is what we targeted first, so that can be broadly adopted in many potential hosts of FL aggregation servers. It is suitable for most applications in need of privacy, although still requires certain assumptions to be met such as the number of nodes within a round, and other factors.
I love how you found a niche, valuable problem, built a framework, and are seeing a lot of success. A question (and I'm far from an expert so let me know if the assumptions are wrong):
It seems to me that the federated users have to be coordinated around timing for this to work. Otherwise this could take weeks/lots of slack messages for a single model to train. E.G. one team is having infra issues and doesn't get a job started, the other team is ready but then their lead goes on vacation, etc... In the internal-to-an-organization case this is probably fine (E.G. a hospital where the data has to be separated by patient/cohort), but if there are different teams managing the data then (a) have you seen this problem and (b) do you have tooling to fix it?
Flower tries to automate this as much as it can. In cases where multiple organizations are involved, the workload can run in a fully automated manner if that's fine for all organizations. If a review step is required, that can be integrated (either on the client side or on the server side) - the availability of reviewers will then become the bottleneck for end-to-end latency.
In the long run, we will evolve the permissioning system to allow workloads to be automatically executed if they fall within pre-approved boundaries, or require manual review if they don't. Pre-approved boundaries could, for example, be used to configure a particular combination of models and hyperparemter ranges that are ok to run without additional (manual) approvals.
FedML is definitely much simpler and more powerful in both research and production. In terms of scalability, I like the benchmarking results in this paper (https://arxiv.org/abs/2303.01778); it shows that FedML is much more scalable. I also tried it myself, it's faster and more scalable. In terms of "research to production", I don't see Flower supporting any MLOps functionalities. Is Flower trying to copy FedML again in this direction?
I will stop here due to your disrespectful words. Good luck.
In fact, we are in the process of implementing LightSecAgg, and we'd welcome their feedback once we have a working version.
Is it possible to create a conversation or QA style interaction with it? I see there's examples of "pytorch" but as a someone new— I'm not sure what that means in terms of public use cases.
I guess I'm asking is "ok I use Flower to train on a bunch of stuff... then what do I do with that?"
Thanks!
After the training, you can deploy the model in different ways. If you want to use it on device (or in one of the organizational silos), you can send the final model parameters there and deploy it locally. Or you just deploy the model on the server behind an API. It all depends on the use case.
Hope that helps, I'm happy to provide more details.
Flower does a lot under the hood to support these different usage scenarios: it has both a networked engine (gRPC, experimental support for REST, and the possibility to "bring your own communication stack") and a simulation engine to support both real deployment on edge devices/server and simulation of large-scale federations on single machines or compute clusters.
This is - to the best of our knowledge - one of the drivers of our large and active community. The community is very collaborative and there are many downstream projects in the ecosystem that build on top of Flower (GitHub lists 748 dependent projects: https://github.com/adap/flower/network/dependents).
Have you had any luck convincing hospitals / insurers / etc that this satisfies HIPAA and is safe? How do you convince them?
Let's say we're building a medical segmentation model, which takes a patient image and outlines a tumour (or some other feature that's unique to them). I am not sure this matters here, but let's say the model is a basic 2D U-net. Image pixels in, binary pixel labels out (cancer/non-cancer).
At a high level, how would a differentially-private setup work for training such a model across multiple institutions without pooling their patient data?
Others asked similar question regarding comparable projects. What's your take on OpenFL from Intel? Do you think Flower moves into more commercial-MLOps direction? Looks like OpenFL particularly focused on to academic imaging community.
Interesting.
Flower seems to fit well for people who are sensitive about their data and don't want to hand it over to a third party, but this seems to move towards a model where they have to hand that sensitive data over to a third party.
Perhaps that still works for the bulk of users, especially commercial rather than government. It's difficult to pursue both a managed solution and simultaneously maintain an open source offering without one departing from the other.
Have you though about what happens at inference? Suppose I train in a federated healthcare environment using PII features from patient records. Once I get the weights back how can I ever deploy it if I don't have access to the same features? The models would become highly coupled to the training environments no?
Best of luck!