4 ms·
The point that ML practicioners are making is not that machine learning beats every other algorithm, or even that they beat humans at specific tasks. The point
by candiodari 9y ago
The point that ML practicioners are making is not that machine learning beats every other algorithm, or even that they beat humans at specific tasks.
The point they're making ML practicioners acceptable at every task. You learn ML and you can have great indexes for your databases, inverse kinematics, cancer treatments, and youtube movie generation that actually gets views, all using the same theory.
Like in the 1980s, that humans can assemble cars with a greater success rate than machines, and can fix the ones they don't assemble correctly, it didn't matter. Humans still beat machines at various metrics in car assembly.
That you can write a program do 1% better at a specific task than an algorithm that can solve every task won't matter.
- zzzcpan 9y agoWe are not talking about 1% better, but an order of magnitude better.
- geofft 9y ago> The point they're making ML practicioners acceptable at every task. You learn ML and you can have great indexes for your databases, inverse kinematics, cancer treatments, and youtube movie generation that actually gets views, all using the same theory. Just to make sure I'm understanding you right - the claim is that you want an ML person on your team (or you want everyone on your team to know ML the way that everyone on your team knows calculus and Shakespeare, i.e., so they can brush up on it as needed), not that human domain knowledge in ML replaces human domain knowledge of what a database does, or what inverse kinematics is, or how to measure cancer, or how to film movies or draw animations, right? The latter is definitely a potential future, but I don't think we're there yet (but I might be wrong!).
- candiodari 9y agoWe're definitely not there yet. Right now it's just one domain after another (slowly) getting replaced by ML. It'll expand though.
- geofft 9y agoBut I don't think these are domains getting replaced by ML, any more than domains were replaced by calculus, or machinery, or even computers. Sure, cancer researchers need to know something about programming now, but they also continue to need to know more things about biology. Is that different for ML?
- PeterisP 9y agoIt kind of is. For a specific example, a decade ago face recognition, speech recognition and machine translation each incorporated a lot of domain-specific knowledge and were largely disjoint fields, since doing anything remotely useful required the specialized knowledge that the subfield had accumulated over the last decade; but nowadays a face recognition ML expert can achieve state of art speech recognition while not knowing a thing about phonetics, and a speech recognition expert can train a decent end-to-end MT solution while being ignorant about all the language/text specific cases that required particular attention and specialized solutions and subsystems some 5 years ago. This is quite a big practical shift in ML; we moved from research on specialized solutions for separate problems to generalized solutions that work on large classes of problems with minimal adaptation, highly reducing the need for domain-specific knowledge. I mean, it's still usually useful, but not absolutely necessary as it was before.
- tincholio 9y agoDon't you need to have domain expertise anyway to engineer your features? What exactly will you train your speech recognition models on, if you have no understanding at all of speech? It may definitely lower the barrier of entry to those fields, but I'm not sure it has removed it altogether, at least not just yet.
- PeterisP 9y agoWith modern deep learning methods, you often can get state of art results without any feature engineering whatsoever - you do need a decent efficient representation of the raw data, but that's about it. That's the whole point, in many domains the accumulated knowledge about feature engineering isn't necessary anymore, since you can train a deep network to learn the same features implicitly from data, and (depending on the problem) it's quite possible that the learned features in the initial layers will be better than anything people have engineered before. For your speech example, speech recognition models used to contain explicit phonetics systems (where the chosen set of phonemes mattered), separating acoustic models and language models. But now you can also get decent results from an end-to-end system, by throwing all the phonetic knowledge you had into the trash bin and training an end-to-end model from the sound data (though, not a waveform but a frequency domain representation, e.g. https://en.wikipedia.org/wiki/Mel-frequency_cepstrum https://en.wikipedia.org/wiki/Mel-frequency_cepstrum - but that's not "understanding of speech", it's understanding of audio data format) straight to the output text characters.
- tensor 9y agoConsider this scenario. You can buy two different databases, one using your ML learned indexes, or another using the hash discussed in the article. For the hash database, it's 2x faster, up to 20x more memory efficient, and doesn't need training. It works on your data reliably from day you spin it up and throughout any changes to the stored data. Meanwhile, your ML indexed database is going to be much slower out of the box, it will only be fast after learning on the data. Worse, if the data changes significantly it will need need to be trained again before being performant. And after all this, it still won't be as fast as the hash database. For development, the ML based index technology won't be faster to build either. If anything, it will probably be much slower as there are all sorts of tricky nuances to building production grade ML systems. When do you train? How do you validate the training data? What do you do if the results don't validate to a sufficient accuracy? I think it's fascinating that ML can be applied to problems like indexing, but if you can produce a deterministic theoretically optimal algorithm, you should use that instead of ML every time.