On a side note... data pre-processing is often viewed a side job that needs to get done before the real work can begin. I don't think I've ever been able to prepare a data pipeline without making decisions about the data that will impact the outcome. For example
How do you deal with missing data? Interpolate, ignore, use averages, use a machine learning algorithm to plug the gaps?
How do you decide what data sources to include in the pipeline. What if one data source seems more reliable, but another has far more data, too much to use. Should you amplify it, sample from the other data sets to make the volumes equal, keep things proportional?
What if one data set changes more rapidly than another, how should you update the data set used to populate the ML model?
These are just a few that jump into my head, and while there are techniques to deal with them, ultimately, there isn't a correct answer. And honestly, even these examples make it all seem more glamorous than it is, a lot of this is just figuring out why various encoding and formatting errors are breaking the feed, why column headers mysteriously change, why handwriting on form scans gets properly translated into text some of the time and completely garbled in others.
The funny thing is, I do see people fine tuning ML algorithms (kaggle style, seeing if they can wring a bit more predictiveness out of a model), when in the real world projects, decisions upstream about the data pipeline will have an impact perhaps 5-10 times greater than any tweak to the ML parameters (or even which general algorithm to choose). And yet, it's hard to get people to even pay attention to these decisions, probably - as you said - because people find it catastrophically tedious and boring.
I'd much rather hire a good programmer with some statistical knowledge than the other way around.
Ultimately, you need a team with a combination of strengths if your product requires multidisciplinary work. Otherwise you end up with hilariously wrong equations/assumptions in your code base. But, full disclosure, my background is math/science.
not ML.
By your argument, the money is in data hoarding and brokering, and renting that data (with DRM) to ML outfits, not doing ML.
Anyway, cleaning dirty data isn't execeptionally hard, it's just boring work; getting the raw data is the hard part.
I think in practice, what happens is that there's no easy transactional boundary that can keep the data ownership and ML in separate firms. The theory of the firm [1] states that firms arise when transaction costs are less than the economic inefficiencies of centralized resource allocation. There are some pretty heavy transaction costs between doing data cleaning and data science in separate organizations:
1.) DRM for datasets isn't really a thing, since to explore, visualize, and train on them, you need access to the raw data, and then instead of your machine-learning function you can just pass the identity function to get the raw data. DRM for consumers always relies on a publisher whose incentive is to stay in business (by not breaking any laws) rather than to obtain the raw data.
2.) You don't know whether a cleaned data set will be useful for your ML application until you've inspected it, visualized it, run some statistics over it, etc. at which point you've done most of the work for setting up your models. That means there's a big risk premium for buying data, and potential buyers usually want samples & statistics before committing a lot of money.
3.) At the price that good datasets go for, you're usually dealing with enterprise sales, which involves commissioned salespeople, face-to-face meetings, expensive dinners out, etc.
4.) The type of labeling you need to do is often intimately connected with the usage of the ML model. What constitutes spam? What constitutes abuse? These are questions for your policy team, which the data-collection organization would have no visibility into and no way to set up a one-size-fits-all policy that all potential customers would be okay with.
5.) Software markets tend to be winner-take-all, which means you're dealing with a handful of customers, and one will likely become dominant and able to acquire you.
Instead of separate firms for data ownership, ML, and user interface, usually the service that makes the final product will end up collecting or buying the data outright, hire data-scientists to do the ML, and then offer a product. The end result, economically, is what you say: the money is in data hoarding. But it isn't apparent in prices of a sustainable customer ecosystem, it's apparent in acquisition prices for startups with data vs. salaries of data scientists.
Functional Encryption[1] is aiming at this exact problem. It's still really early stage, and it currently has a lot of caveats (the current algorithms are really expensive and only able to work with linear function AFAIK), but the field is moving rapidly, and we don't know how far it will get. There's also Fully Homomorphic Encryption [2], which is way cheaper and more versatile, but in that case, only the owner of the data can get the result of the calculation.
None of this is currently used at scale, but their is a lot of research on this field and some PoC are being built at Microsoft and IBM IIRC. There's also Cosmian[3], a French startup working on this topic. (Full disclosure, I know the founders)
[1]: https://en.m.wikipedia.org/wiki/Functional_encryption
[2]: https://en.m.wikipedia.org/wiki/Homomorphic_encryption#Fully...
[3]: https://cosmian.com/
There is. Data broking is a well established business model in finance. Every bank and hedge fund is running ML models on data licensed from a provider such as Reuter’s, S&P, etc there are dozens of such brokers.
Everything else is noise. For any proposed ML project, the first question you should ask is "Where are you going to get the training data?"
If someone tells you "Oh, getting data will be the easy part", back away very slowly :)
One thing I’ll mention is that this is true both at the very early stages of a ML project, and even when an ML project is scaled up and in production. Oftentimes, the data pipeline is the true way in which a model will improve versus anything else, so it’s pretty critical that these data pipelines are setup to get an initial dataset but also to scale properly.
It’s one reason I started Scale (scale.com). It was viscerally clear that the real bottleneck to ML was getting the needed data, and in our case, annotating that data appropriately. It is very heartening to hear it echoed in this whole thread that data is very clearly what “matters” for ML.
This is the most basic securities data that exists in finance, perhaps you can even get it for free from some Yahoo or other retail data source.
If you just want basic financial data there are easier ways, e.g. the Quandl API (not affiliated).
But the bigger issue is that you can't accurately label your training data. A subsequent stock price move could have been due by something revealed in the 10-Q that the market somehow missed, or it could have been caused by a forest fire in Bolivia, or a competitor getting acquired, or any combination of near infinite external events that couldn't have been predicted from the 10-Q.
Time to setup up scikit learn and tensorflow algorithms to make predictions: 4 hours. Time to setup python scripts which could parse through the excel spreadsheets, figure out which row corresponded to gross profit margin, and a few other "standard" metrics: ??? unknown because I gave up at about 80 hours trying to figure out rules to process all the different spreadsheets and how names were determined.
I had a professor who was doing machine learning + chemistry. He was building up his own personal database for machine learning. He spent ~5 years with about 500 computers building the database so that he would be able to do the actual the machine learning.