You can see some of my work here:
https://medium.com/capital-one-tech/why-you-dont-necessarily...
The reality is, you can guarantee certain values are not passed. That’s fairly easy, what you can’t do is block general trends easily in synthetic data - else the model can’t learn. So you have to be willing to accept that “leakage” when using synthetic data.
If you accept that leakage, then you can actually improve model performance in some domains. See ubers architecture search blog, there’s a lot of material (also from Uber) showing this.
Regarding cost of training, yes model training costs could increase. Although, I’d suggest much much less than 10x more like 50% or something. Is that worth it for privacy?
Nonsense. There's a fundamental requirement that for a model to have utility, it must have access to relevant data. If you truly find a leak-proof way to block certain values (which is borderline impossible in itself), then you make the model significantly weaker or outright useless if those values aren't uniformly distributed across the input domain.
And if you do have leakage (and you almost certainly do), then direct re-identification becomes a trivial problem and we're back to square one.
Synthetic data generated from statistical analysis of real data is either worthless or leaky. One of those two conditions is formally guaranteed to be true.
GP is correct that a viable synthetic data generator basically has to have already solved your problem for you, and in that sense it just becomes your model which is trained on real data. Training an additional model on top of that model doesn't add any privacy or mitigate reidentification.
Guaranteeing that certain values are not passed is both useless and trivial. I can easily satisfy that by simply adding 0.1 and a space character to all values in my dataset even though that doesn't remove any of the sensitive data.
The idea that training on synthetic data is a “charade” misunderstands the usefulness of having realistic, “drop in compatible” data that works with your existing code or models.
The ideas of training models as a service and also of working directly with synthetic data generators to “extract“ from them are great but incompatible with (a) the complexity of real world DS workflows in regulated industries and (b) data scientists current code / workflows / techniques.
If I’m a bank, I’m not going to give you my fraud rules and you’re not going to solve my problems with xgboost. Access to models is just as locked down as access to data.
This is why it’s useful having an intermediary. Like ... a generative model that you can train where the data is and then copy over to where the modelling is happening.
As an intermediary like you describe is far different than "I don't have enough real data for what I want to do", for example.
Assuming the problem at hand is analyzing the data.
I don't know enough about what they're building to understand what use cases they have in mind. (Their blog says "developing new features or exploring insights", which is a bit vague. See https://medium.com/gretel-ai/gretel-readme-fd0c4eff8a09 .)
But if this allows people to take their production database, run a command, and generate fake data they can run integration tests against, then that's not analyzing the data. It's making it easier to run tests in an environment that is as close as possible to production, because data is part of an environment.
Aside from that, I'd argue that some kinds of analysis may even still be possible. Let's say you have an e-commerce site, with one database table for user accounts and another table for shipping addresses. And let's guess that Gretel anonymizes this data by creating a user table with different usernames and an address table with made-up shipping addresses, but the overall structure is isomorphic: for every row in real data, there is a corresponding row in fake data, just with different values in it. And the (synthetic) keys aren't private (they data you generated, not collected from the user), so they can be preserved. Then you can, on the fake data, run a query and find out what percentage of users have given a shipping address.
Of course it's just a guess that that's what they're aiming to do since so little detail is available. It's entirely possible that what I described isn't what they're planning to do. Maybe it doesn't sufficiently protect privacy.
But the point is, until we know what they're building, I don't know if we can conclude that people should run away.
At the risk of digressing from TFA, Candes’ knockoffs, for instance, are an example of a (theoretically) successful use of synthetic data for model robustness. Still need original data, of course.
Basically, the broader point is that you don’t need to solve the full problem of joint likelihood estimation to use generative models effectively, e.g., GANs are another example.
Example: Training an image upscaling algorithm by feeding it downscaled images. In this case you don't even need to train a generative model (the algorithm is known), but it should illustrate that the generative task can be extremely easy compared to the target task. You can't just handwave that away with "just divide by P(X)".
1. Already doing that, in which case it's already the superior model.
or
2. Not doing that correctly, in which case the synthetic data output is equally poor.
Other examples I could think of fall in the category the top comment is referring to.
I've heard this group is pretty good, and they seem to be proud enough of their synthetic data to publish papers on it:
https://ai.googleblog.com/2020/02/generating-diverse-synthet...
Illuminate me, why are they wrong?
Generative models do not necessarily know P(X,Y), often they simply give samples of (X,Y) using some map
G: Q -> (X,Y); Q~N(0,1)
Actually getting P(X,Y) would mean inverting G, which is not always possible (although there are some invertible GANs).
Computing P(X) is often computationally intractable as tracing out variables can be arbitrarily expensive.
I'm being pedantic by posting this though, because their approach involved learning the synthetic data generator simultaneously with the classifier/whatever that you're training. That is not relevant for a static synthetic data source.
So, what do you get out of it compared to simply training models as a service for people? Almost nothing useful. All you get are:
- Much worse privacy guarantees. (People selling synthetic data love to talk about improved privacy, but it's actually the reverse. The privacy guarantees for synthetic data are much, much worse than selling direct models to people.)
- Much worse model performance. See the previous notes about how a synthetic data generating procedure must have already solved the problem at hand.
- A much more complicated setup with much more expensive model training. Training generative models is hard and requires a lot of data and compute due to the difficulty in learning such a complex outcome space. This can easily cost 100-1000x as much as simply training a straightforward xgboost model.