3 ms·

But isn't all this just old wine in new skins? Is there really a difference between "labelling data" and assigning properties to "traditional" inputs (e.g. ass

by qayxc 5y ago

But isn't all this just old wine in new skins? Is there really a difference between "labelling data" and assigning properties to "traditional" inputs (e.g. assigning tax codes, classifying new products, filing cases, managing customer data, ...)? Is there something fundamentally unique about sharing and monitoring data during ML training as opposed to say feedback loops between trading algorithms and profit or production planning, logistics and market response? Or to address your examples, wouldn't the same issues as in your motorcycle detector arise with any other software implementation? Hardware constraints, runtime limitations and -requirements are in no way unique to ML after all. The same applies to your spam detector example. The same questions arise with any other software. It's all just constraints versus benefit, data quality, monitoring loops, infrastructure, and cost. I honestly don't see anything that's truly unique to ML here. The part that is described as "model training" in ML is just done manually by developers and expressed as iterations in engineering. I would therefore think that the skillset is very much transferable and much of the apparent novelty is just traditional software engineering and management practices hidden behind ML jargon.

kajecounterhack 5y ago
> I honestly don't see anything that's truly unique to ML here. - The workloads are specific (lots of offline batch processing, accelerator powered offline stuff, then speed/power/resource constrained inference stuff) - The hardware is specific (ML accelerators are for ML, you don't really use TPUs for anything else do you?) - Debugging is specific (ML-specific tools like XLA) - Labeling is specific (e.g. labeling audio, video, 3D points requires specific tooling) If what you're saying is, "ML engineering sounds like engineering" that's obvious and was never a point in contention. OP's comment was "a couple of motivated engineers can make ML work" and my point is -- kind of, but at scale you need a lot of very specific things which are best done by specialized folks. That there are billion dollar ML infra companies, as well as companies with ML infra teams that are hundreds of people, means that folks are finding it worthwhile to have, say, a team of folks who work on deploying nets efficiently and only that. Or a team of folks who only build labeling tools. Or a team of folks who only build model evaluation tools. My ramble was mainly to illustrate just how many sub-problems there are in ML and why ML infra is rightfully a big business -- there's a reason companies that use a lot of ML don't just have 2-3 randos building everything end-to-end for each model. > The part that is described as "model training" in ML is just done manually by developers and expressed as iterations in engineering. I would therefore think that the skillset is very much transferable and much of the apparent novelty is just traditional software engineering and management practices hidden behind ML jargon. Yeah ML engineering is engineering, so plenty of skills transfer between ML engineering <-> other engineering. But if you want to go from other engineering -> ML engineering, you do have to learn ML-specific things that I would not dismiss as "novelized software engineering" or just "jargon."

by qayxc 5y ago

kajecounterhack 5y ago

> I honestly don't see anything that's truly unique to ML here. - The workloads are specific (lots of offline batch processing, accelerator powered offline stuff, then speed/power/resource constrained inference stuff) - The hardware is specific (ML accelerators are for ML, you don't really use TPUs for anything else do you?) - Debugging is specific (ML-specific tools like XLA) - Labeling is specific (e.g. labeling audio, video, 3D points requires specific tooling) If what you're saying is, "ML engineering sounds like engineering" that's obvious and was never a point in contention. OP's comment was "a couple of motivated engineers can make ML work" and my point is -- kind of, but at scale you need a lot of very specific things which are best done by specialized folks. That there are billion dollar ML infra companies, as well as companies with ML infra teams that are hundreds of people, means that folks are finding it worthwhile to have, say, a team of folks who work on deploying nets efficiently and only that. Or a team of folks who only build labeling tools. Or a team of folks who only build model evaluation tools. My ramble was mainly to illustrate just how many sub-problems there are in ML and why ML infra is rightfully a big business -- there's a reason companies that use a lot of ML don't just have 2-3 randos building everything end-to-end for each model. > The part that is described as "model training" in ML is just done manually by developers and expressed as iterations in engineering. I would therefore think that the skillset is very much transferable and much of the apparent novelty is just traditional software engineering and management practices hidden behind ML jargon. Yeah ML engineering is engineering, so plenty of skills transfer between ML engineering <-> other engineering. But if you want to go from other engineering -> ML engineering, you do have to learn ML-specific things that I would not dismiss as "novelized software engineering" or just "jargon."