Hacker News Reader

Comment by headcanon | Hacker News Reader

I'm a bit unclear on the goals for this startup. When you say "Github for Data" I'm thinking of a repository of datasets used for ML training or for more traditional research. But this:

> This so-called “synthetic data” is essentially artificial data that looks and works just like regular sensitive user data.

So its like Lorem Ipsum generator for data? Whats the use case here besides building apps with sample data? Notwithstanding potential privacy concerns, How am I confident that this is realistic if you literally say its generated?

General data repository for research with some mechanism to ensure cleanliness or integrity sounds much more useful to me.

View on HN

As you have noticed, "Github for Data" is not what they're building. At all.

Our company is actually building Git for Data and Github for Data. We have an open source database called Dolt which combines the commit graph of git with the relational tables and SQL of MySQL:

https://github.com/liquidata-inc/dolt/

Then we have a DoltHub, which is Github for data:

https://www.dolthub.com/

Dolt lets you version, branch, and merge your dataset so that you can collaborate on it with others. Dolthub lets you share your dataset with the world, submit PRs, fork other people's repos, and lots of other analogous features to Github.

You might want to re-think that name: https://www.urbandictionary.com/define.php?term=dolt

> A mental retard who is clueless not only about current events, but also has the IQ level of a rock. "Dolt" may be the most sophisticated insult in the English language. Dolts commonly populate such stereotypes as jocks, nerds, fruits, bookworms, and dorks.

It's probably intentional, because "git" is also an insult to imply somebody's dumb.

True, but the name `git` came from the open source SCM tool, written by Linus for the Linux source code - and now everyone is sort of stuck with that name. This is a commercial product, deciding on a name for themselves.

Also, at least in British English, calling someone a git doesn't mean "dumb" it means "mean/nasty/malicious".

It's paying homage to how git was named:

https://en.wikipedia.org/wiki/Git#Naming

I was thinking of https://www.folklore.org/StoryView.py?story=Do_It.txt (nice story about Tesler at Apple, by the way) and hence, reading it that way :-)

Is DoltHub also open source?

No. Like Github, Dolthub is closed source.

That's unfortunate. I hope you a open source version pops up, or DoltHub becomes open source.

It appears they've got an open source licence on Dolt, which is a CLI tool to be used in tandem with DoltHub?

> How am I confident that this is realistic if you literally say its generated?

This is a particularly good question since it's recently been shown that even neural nets trained on real data often pick up substantial, predictable dataset biases.

Practically every single-dataset-trained CNN seems to pick up stylistic quirks in the photos or labels it's trained on. The most visible result is that the CNNs perform better on same-dataset test examples than they do in the wild, sometimes vastly better. More startlingly, it's possible to work backwards from this: the training source of a "finished" CNN can be discerned by looking for certain types of error, and adversarial examples can be predictably constructed based on training source.

Tagged imagesets undoubtedly have stronger and harder-to-remove 'fingerprints' than text data like addresses, but I'd be shocked if the problem was nonexistent for text. My first reaction to "synthetic sensitive user data" for ML is to worry about winding up with systematic errors coming from the generation scheme.

cf "radioactive data" to tag datasets and see which downstream models used those datasets for training: https://ai.facebook.com/blog/using-radioactive-data-to-detec...

The concept is that you're carrying over the same general topology of the real data but in a way that is effectively non-sense. This allows you to build ML models that are representative of the parameters of the true data which you can then use for inference systems in production.

It's a technique we've used in the DoD a long time and it works ok when everything is perfect. There are a lot of boundary problems like being able to troubleshoot bad data if you are doing your initial analysis with the transformed data, having DS's actually grok the problem-set since it's abstracted etc...

Edit: It's worth noting that this is a technical solution to a policy/legal roadblock. As organizations mature into better data governance, they are pushing more fundamental changes to governance that gets at these problems where solutions like this will no longer be necessary. For example, hiring data scientists into the groups that have access to the raw data (in our case hiring data scientists and giving them security clearances).

Except that if their models have already inferred sufficient structure from your data to do this in a way useful for training, then their models have already solved the problem your models are trying to learn.

As a point of clarification it's not the model that is being abstracted, it's the raw data.

The use cases that this addresses are ones where you cannot train models in the same system/space/network as where the data exists.

In health care AI there is some tendency to use generated data for training. Idea might be that org A has real patient data but for privacy reason cannot share data, but if they create a sufficiently strong generator they can share that and org B can train their classifier without ever accessing sensitive data. Alternatively, it can be also used if you simply have too little data and need augmentation.

This just seems like something that will catastrophically fail. If you can build a good enough generator you can just build the ML model internally. And if you can't the statistics of what you provide are going to be off enough that any strong model is going to be wrong in strange ways.

You can still pretrain on synthetic data and finetune on a smaller dataset of real data.

Fraud modeling, regulatory requirements, economic data share (e.g. internal firm data) all represent potential use cases.

This is an incredibly important point: in order for your synthetic data to be useful your simulator must have already solved the problem at hand. In theory there is no need to even fool around with generating the synthetic data and going through the charade of training a model on it; simply exact the outcome model from your simulator directly as that's implicitly what you are doing. For example, if you have a generative model that provides densities, you can simply compute P(Y | X) = P(X, Y) / P(X).

Mathematically valid but misses the business problem :)

Very true. If you've solved the labeling/extraction problem using a means other than ML, you can use that means to generate synthetic data. The situation at my company is exactly this.

Say you use regular expressions to extract sensitive data from standardized, but numerously varied, form documents. The pieces of information extracted are very common classes of data: first name, last name, dates, physical locations.

During the extraction process you can save the complement of the extraction (the "leftovers") and insert generated data at the extraction points. Also, because you've extracted the actual sensitive data, you can exclude that from the set of values used for generation, if it's practical.

Sometimes people get caught up in the math and theory that they fail to see the practical solutions.

But this is not how generators work. They generally produce samples in the from

G: Q -> (X,Y)

where Q is some prior from which you are sampling. If they are not invertible then you straight up cannot get P(X,Y) out of the generator. Even if it is invertible getting P(X) requires integrating out the Y which might be infeasible (since the model is not integrable and is sufficiently fast changing that you need very, very many samples).

I agree that this is very tricky. I think the most interesting synthetic healthcare data generation I saw was using causal inference (where SMEs can bake in a bunch of expert knowledge during skeleton construction) and then generated data by getting the weights on the edges from a smaller dataset. At the same time, it is very hard to ensure that you synthetic dataset actually reflects real world. On one hand SME knowledge might give extra oomph to synthetic data generation (as this knowledge is equivalent to some highly abstracted training) but also if the "expert knowledge" is wrong then it's a recipe for disaster.

> In health care AI there is some tendency to use generated data for training.

Which is part of the reason for the high failure rate.

Good governance and data access for health data is a very hard problem. Good labeling is also hard/expensive in this space.

So there is an incentive for people wanting to do ML/AI without solving above to try any kind of shortcut they can think of. This incentive doesn't help solve any real problems.

The classic solution to "too little data" is use a simpler and/or less discriminating model. It's still the only one with a good track record.

> The classic solution to "too little data" is use a simpler and/or less discriminating model. It's still the only one with a good track record.

Kind of, transfer learning is an important tool that people should use more.

Transfer learning is nothing like a silver bullet. True, it has become an important work around but it's no panacea and the track record is at best mixed.

People already use it quite a lot. More importantly they misuse it a lot. I'd be less concerned with increasing the usage, and more concerned that the people using it understand the implications and trade offs.

Gartner estimate that by 2022, 40% of AI/ML models will be trained on synthetic data.

Just because it may have some drop in utility today from real data, there are all sorts of scenarios where that’s outweighed by speed and ease of working with fake data rather that tied up in red tape real data.

See for example: https://hazy.com/blog/2019/12/09/data-science-on-test-data

Also, synthetic data can be augmented, rebalanced etc. Which is why in future it may well perform better than real data for data science work.

For example, think about this person does not exist and then apply that to business data.

Disclosure: Hazy cofounder. We’ve been doing smart synthetic data for a few years now.

https://forensic-architecture.org/investigation/cv-in-triple...

Also this for a practical use of synthetic data.

The "mays" in this statement are doing a lot of work.

There are a few areas of current practice that have this feature: a) the arguments & evidence for it being worse are pretty simple and b) the arguments & evidence for potential benefits are either weak or very convoluted. This is never a good sign.

I think this happens mostly because the reasons these things are being done are for the most part not technical, but the technically oriented people involved don't like to think about that way, and would rather talk about technical solutions - but that is operating at the wrong data.

The business & cost cases behind not doing this "right" in some abstract sense are pretty clear too, though. I wish more people would just be clear about this, and spend less effort obfuscating and more in clearly quantifying the cost of these workarounds.

Any time you hear someone starting off by saying things like "we don't really need good labels", "this synthetic data will be better, actually", "we'll use transfer from X because it's already done most of the work", etc., well what follows is quite likely to be good fertilizer.

Note, I'm not saying these approaches don't have value, just that there is an awful lot of magical thinking going on around it, and a lot of failures due to that.

There’s only one “may” there but yes, it masks “potentially losing crucial information”. The post I linked to is pretty clear on that.

I totally agree that the business need is the driver and that people miss the imperatives if they look at it purely from a technical or mathematical lens.

In a sense, synthetic data is the least bad actually viable solution. The democracy of privacy / data agility :p

I was referring to both "it may have some drop in utility today... " and "in future it may well perform better than ..."

My issue is not that people just miss the imperatives, but that they also misapply effort because of it. Accept there is a cost and try and quantify the impact. Make intelligent risk management decisions based on that. Sometimes that decision is "this is unlikely to work, what else can we do".

I wonder if "synthetic data" could be used to proof ML? Ie, rather than start from a huge data set that you _think_ is clean enough to know what a Car is (or w/e), you could use a data set that is perfectly clean and the ML set could be tweaked to give the expected result.

Of course, that would still be hairy as you'd have to ensure your ML still performed on real data sets. All the clean data would do is allow you to write unit tests of sorts for your ML with more confidence than the all-too-common unclean real data.

No idea, just making stuff up. Interesting thought.

It seems to be targetting pre-production release startups/companies who need access to real data, structured and appearing exactly like real APIs they intend to roll out in production, from which to build their products. Then when it goes live it switches to the real data feeds which this company's API directly mimics.

That's what I'm guessing. It could be used for AI stuff but also other useful datasets that are closed off or require special access.

I'm guessing a lot of defence contractors and other heavily regulated industries (ie, healthcare, insurance, pharma, etc) have similar problems in the dev process of not having access to real data. This was the leading pitch:

>> Data is valuable for helping developers and engineers to build new features and better innovate.

That's just my guess though.

I would be really interested in a "github for data", just a place you can upload structured data of any kind with a bit of meta tagging for public consumption.

SDR captures PCAPs Microphone captures Public tax records Road data Flight plans etc...

Just anything and everything on one service with the limitation that it's all open data. No license agreements or legal restrictions.

It would probably never fly, but it would be amazing.

Maybe they use something unusual, like homomorphic encryption?

Would be too cool!

It's a cool idea, but you can't yet apply homomorphic encryption and then ML and get anything useful. You can do more limited data obfuscation.

Reply on news.ycombinator.com