4 ms·

My limited opinion: The Right Data is better than Big Data, if you can get it. There was a push to get data out of app dbs and into big data repositories. But

by csours 8y ago

My limited opinion: The Right Data is better than Big Data, if you can get it. There was a push to get data out of app dbs and into big data repositories. But then no one could use the big data because it made no sense. So then ML? But if you already know what it means in the app db, just make it available in a sensible format.

erikb 8y ago
I think you can have both situations. I still remember a talk from a Google person maybe around 2010 where he showed clearly that if you try to make the data "better" but in general have way too little data points, then it can't be useful either. It's just now that we had almost a decade of pushing towards more IoT and more Big Data, that many companies have huge data lakes that they don't know how to make use off. So instead of applying one of these lessons it's probably best to see where one is lacking (quantity or quality) and work on resolving that specific problem accordingly.
jrumbut 8y ago
One of the most interest HN comments I saw last year claimee many programming trends that burn out make false promises about not needing to worry about database design anymore. The insights you're looking for could be cutting research problems or near trivial depending on the condition of the app db. I have become fond of saying that the opportunities of ML and data science are just more rewards for getting your database schema right.
nestorD 8y ago
There is a very good talk on "The Unreasonable Effectiveness of Structure" that detail how just adding this structural information instead of droppping it can give great, low-hanging, rewards : https://www.youtube.com/watch?v=t4k5LKCpboc https://www.youtube.com/watch?v=t4k5LKCpboc
jillesvangurp 8y ago
ML definitely works better on good data. If you have bad data, putting some effort into turning it into good data can get you a lot of decent results very quickly. Whenever you hear a ML experts talk about 'feature extraction', they are talking about turning unstructured data into more structured data. With unsupervised learning, you rely on this happening automagically. I've seen some naive approaches struggle to get good results when all that was needed was beating some sense into the data. This typically requires domain knowledge. IMHO most of the engineering effort in ML is not tuning the algorithms but moving data around. A little practical example: consider a dataset containing POIs and a ML based search ranking algorithm that is struggling with correctly ranking airports. Do you 1) spend a year trying to get your algorithm to work better using examples of 'good' results, or 2) figure out a better source for the limited number of airports that exist in the world with better metadata. Turns out a ~day of sorting this out with a few good open data sources gets you a lot further than months of trying out different ways to extract features that aren't there. We had a whole team of ML PhDs. on this and they couldn't get it done. A single engineering intern came up with the obvious analysis: this data is shit, fixing that is easy, lets fix that. Problem solved.

by csours 8y ago

erikb 8y ago

I think you can have both situations. I still remember a talk from a Google person maybe around 2010 where he showed clearly that if you try to make the data "better" but in general have way too little data points, then it can't be useful either. It's just now that we had almost a decade of pushing towards more IoT and more Big Data, that many companies have huge data lakes that they don't know how to make use off. So instead of applying one of these lessons it's probably best to see where one is lacking (quantity or quality) and work on resolving that specific problem accordingly.

jrumbut 8y ago

One of the most interest HN comments I saw last year claimee many programming trends that burn out make false promises about not needing to worry about database design anymore. The insights you're looking for could be cutting research problems or near trivial depending on the condition of the app db. I have become fond of saying that the opportunities of ML and data science are just more rewards for getting your database schema right.

nestorD 8y ago

There is a very good talk on "The Unreasonable Effectiveness of Structure" that detail how just adding this structural information instead of droppping it can give great, low-hanging, rewards : https://www.youtube.com/watch?v=t4k5LKCpboc https://www.youtube.com/watch?v=t4k5LKCpboc

jillesvangurp 8y ago

ML definitely works better on good data. If you have bad data, putting some effort into turning it into good data can get you a lot of decent results very quickly. Whenever you hear a ML experts talk about 'feature extraction', they are talking about turning unstructured data into more structured data. With unsupervised learning, you rely on this happening automagically. I've seen some naive approaches struggle to get good results when all that was needed was beating some sense into the data. This typically requires domain knowledge. IMHO most of the engineering effort in ML is not tuning the algorithms but moving data around. A little practical example: consider a dataset containing POIs and a ML based search ranking algorithm that is struggling with correctly ranking airports. Do you 1) spend a year trying to get your algorithm to work better using examples of 'good' results, or 2) figure out a better source for the limited number of airports that exist in the world with better metadata. Turns out a ~day of sorting this out with a few good open data sources gets you a lot further than months of trying out different ways to extract features that aren't there. We had a whole team of ML PhDs. on this and they couldn't get it done. A single engineering intern came up with the obvious analysis: this data is shit, fixing that is easy, lets fix that. Problem solved.