Live data from Hacker News

Machine learning is still too hard for software engineers

nyckel.com

111–120 of 154 posts

Re: Machine learning is still too hard for software engineers

#111
post #26

Another perspective, someone with no programming experience whatsoever today can in 1 minute create a new ML application for natural language tasks with performance that would blow most SOTA systems from 5 years ago out of the water, using things like the openai API. And this trend will almost certainly continue, where many tasks can be programmed by simply asking/describing the problem to a massive model and letting…

This seems a trifle hyperbolic. No programming experience whatsoever? Remind me what the 'P' in 'API' stands for?

If one were to build with the API from scratch. But in theory all you really need to do to deploy a “new model” just is write a short prompt and click a “create endpoint” button.

Re: Machine learning is still too hard for software engineers

#112
post #106
post #102

Earlier quoted context omitted.

Most folks don't realize that the vast majority of ML applications can be done with preexisting models, you don't need someone with a PhD to fine tune it unless you need to eek out a tiny bit of improvement. The real value is in the person preparing the data for training.

This is not true at all unless you're only referring to commodity applications. There's no preexisting model for general regression or seq to seq, for instance. You can say, oh, that's a good fit for an LSTM, but you still need to tune the individual layers to suit the application. Although I am slightly conflating ML and DL, since you mention training which heavily implies DL.

Most folks can get away with logistic or linear regression. A tiny portion of those might need to move to random forest. And an even tinier portion may justify deep neural networks. The vast majority of ML is not deep learning, nor is it necessary. We're talking very boring typical business cases.

Re: Machine learning is still too hard for software engineers

#114

Coming from a background in computational quantum chemistry, it’s interesting to see all of the people who say ML is “easy” after taking a few online courses and reading some books on data science. If it’s so easy, invent AGI then, since that is the holy grail of machine learning. Most of these people claiming expertise do not have a deep grasp of the mathematical fundamentals required for state of the art research i…

What does representation theory and Fourier transforms have to do with neural networks (I've not properly studied ML)?

Re: Machine learning is still too hard for software engineers

#116
post #98

I still remember when SQL was a dark science that could only be managed by administrators that were initiated in secret rooms. Nowadays a lot of people use SQL without deep understanding. They do useful stuff but if you are very skilled you can do way more. And SQL experts are often frustrated with all the amateurs that use their database in such a sub-optimal way. I expect the same for ML. The tooling will improve u…

As ML expert, I am often frustrated at the sub-optimal things I find in the wild or even publications. But you need to understand everyone is on a growing trajectory.

And there is also the concept of "good enough".

Re: Machine learning is still too hard for software engineers

#117

It seems to me the biggest challenge for SE transitioning into ML is that ML is a very broad topic and people conflate a lot of roles together. From purely research based questions (backbones, optimizers, initializers etc), to more 'MLOps' like pipelining questions, which tend to fall into the classical engineering / dev ops buckets. So the real question is what type of ML do you want to do? If you're looking to land…

It's interesting that you mention this, because there's quite an impressive resurgence of privately funded R&D going on in the ML space. We're in an interesting phase, where the field is moving too fast to have 'canonical' methodologies (though we're getting close). To be an engineer in the deep learning space often requires reading and keeping up with research. Everything just gets dumped on arXiv, because the peer-reviewed publication cycle is almost too slow for the field.

Making a successful transition to ML in my opinion, depends a lot on the individual. Without a strong background in calculus, linear algebra and statistics, it's going to be difficult. Training a model is what people tend to focus on, but in my opinion, that's the easy part. Evaluating/validating a model, analyzing and preparing your data, anticipating model performance, understanding what to do to improve your fit, model selection or architecture. Developing custom deep learning architectures at times requires a bit of an abstract mathematical intuition that I think will suit many engineers very well. A lot of engineers are well equipped to be successful in making a transition, but on the other hand, at least as many aren't.

In the future, I think the field will have many varying degrees of expertise, with the barriers to entry becoming lower all the time. We're reaching a point where some common use cases can be solved adequately in a nearly automated fashion. Some "autoML" tools don't really require any real understanding of ML, though I think it's not wise to get in the habit of using them without understanding how to evaluate a fit. These tools will be great for people who want to occasionally use ML to solve some smaller problems, but as a part of their larger job function.

In some middle area, ML engineers and practitioners will be training and operationalizing models, and keeping up with major developments in research. But there will be some significant changes in the next decade. I predict the nebulous of data science, data analysis and machine learning will become formalized into 3 major skills - exploratory data analysis, machine learning and advanced computational statistics.

At the lowest level, researchers will continue developing the field, which like you say, is probably not something you transition directly into.

Re: Machine learning is still too hard for software engineers

#118
post #87

The challenge for the engineers at our AI startup is that deterministic testing paradigms don't adapt well to probabilistic models that are continually being retrained. As a scientist is hard to convey the acceptable range of variance and often the random change of individual predictions at the decision boundary. It's also hard debug behavioral issues that actually are systematic model failure versus those that are t…

Good discussion. I have often wondered about that interface.

This bears more resemblance to traditional manufacturing actually. I think there may be some value in borrowing ideas from statistical process control, rather than trying to force predictions into deterministic cases.

Re: Machine learning is still too hard for software engineers

#119

Earlier quoted context omitted.

I tried to build on top of fast.ai, and it was very easy to start, but all the hooks and magic in fast.ai 2 just made it extremely hard for me to understand and extend the code. I believe it went in a bad direction.

When tensorflow was the dominate api, fast.ai made a lot of sense. Nowadays pytorch seems to have won and it is easy to use directly and there is PyTorch Lightning if you want things even easier to write. There are a several videos on youtube where the creator reviews a paper and then implements it from scratch. For example this channel is pretty good: https://www.youtube.com/c/AladdinPersson/playlists

fast.ai is built on top of pytorch just like pytorch lightning

Re: Machine learning is still too hard for software engineers

#120
post #59

Sort of hijacking, but I've always wondered: Where are our 'neural binutils'? I want to be able to compose these tools like I would random unix ones: Something like 'Identify album covers in this image | extract the text in said covers | spotify api'. It seems like there are so many breakthrough models but both due to technical (size/compute) and industrial ($$$) concerns they remain out of reach for random devs, let…

> Where are our 'neural binutils'? Assuming you mean coreutils. binutils is for managing/inspecting binary executables. But to your point: there were two key innovations and criteria of UNIX pipelines: a common and understandable data format, and writing programs to send and receive anonymous data. Crucially, the input and output formats were the same: plain text, separated by newlines. In contrast neural networks ar…

There's still a lot of opportunity to introduce ML into the classic plain text Unix utilities. Even if you have to retrain, there's still room to improve over existing tools. One example is learned sort, which outperforms radix sort, even including the time it takes to train the model.

https://blog.acolyer.org/2020/10/19/the-case-for-a-learned-s...

Post reply on HN