Why is machine learning 'hard'? (2016)

https://ai.stanford.edu/~zayd/why-is-machine-learning-hard.html

by jxmorris12 • 2 years ago

283 140 2 years ago

ai.stanford.edu

jruohonen• 2 years ago

"An aspect of this difficulty involves building an intuition for what tool should be leveraged to solve a problem."

While I agree with the good point about debugging, like many others, I am rather worried that we're increasingly deploying AI/ML where we shouldn't be deploying it. Hence, the above quote.

sjwhevvvvvsj3• 2 years ago

I’m old enough to have learned that the secret to success is much less knowing the tool of the moment than picking the right tool for a job.

The right tool may in fact be the new one, and LLM do open a lot of doors with zero shot capabilities, but oftentimes they can underperform a well tuned heuristic. It’s the ability to pick the right tool that is key.

wwarner• 2 years ago

Want to agree with you, as so many ML apps seem to be solutions looking for problems. But I actually feel that we are rapidly deploying ML in a development context for vastly improved results. The way that good models are built relies on many ML steps, and when the results finally come together the result is superior to what could have been custom designed. Broad adoption of something like probabilistic programming is coming soon.

dang• 2 years ago

Discussed at the time:

Why is machine learning ‘hard’? - https://news.ycombinator.com/item?id=12936891 - Nov 2016 (88 comments)

epistasis3• 2 years ago

Love that thread. The top comment is excellent:

Like picking hyperparamters - time and time again I've asked experts/trainers/colleagues: "How do I know what type of model to use? How many layers? How many nodes per layer? Dropout or not?" etc etc And the answer is always along the lines of "just try a load of stuff and pick the one that works best".
To me, that feels weird and worrying. It's like we don't yet understand ML properly yet to definitively say, for a given data set, what sort of model we'll need.

This embodies the very fundamental difference between science and engineering. With science, you make a discovery, but rarely do we ask "what was the magical combination that let me find the needle in the haystack today?" We instead just pass on the needle and show everyone we found it.

Should we work on finding out the magic behind hyperparameters? In bioinformatics, the brilliant mathematician Lior Pachter once attacked the problem of sequence alignment using the tools of tropical algebra: what parameters to the alignment algorithms resulted in which regimes of solutions? It was beautiful. It was great to understand. But I'm not sure if it even ever got published (though it likely did). Having reasonable parameters is more important than understanding how to pick them from first principles, because even if you know all the possible output regimes for different segments of the hyper parameter space, really the only thing we care about is getting a functionally trained model at the end.

Sometimes deeper understanding provides deeper insights to the problems at hand. But often, they don't, even when the deeper understanding is beautiful. If the hammer works when you hold it a certain way, that's great, but understanding all possible ways to hold a hammer doesn't always help get the nail in better.

amelius• 2 years ago

The hammer analogy doesn't make much sense because for a hammer we can actually use our scientific knowledge to compute the best possible way to hold the tool, and we can make instruments that are better than hammers, like pneumatic hammers, pile drivers, etc.

With your argument, we would be stuck with the good old, but basic hammer for the rest of time.

sjwhevvvvvsj3• 2 years ago

I do a lot of model tuning and I’m almost ashamed to say I tell GPT what performance I’m aiming for and have it generate the hyper parameters (as in just literally give me a code block). Then I see what works, tell GPT, and try again.

I’m deeply uncomfortable with such a method…but my models perform quite well. Note I spend a TON of time generating the right training data, so it’s not random.

ummonk• 2 years ago

This embodies the very fundamental difference between science and engineering.

Not really though. In engineering, you have heuristics, even if you don't know why they work. In the case of deep learning / AI, there seems to be very little in the way of built up heuristic knowledge - it's just "try stuff and see what works for every problem".

logtempo• 2 years ago

Sometimes deeper understanding provides deeper insights to the problems at hand. But often, they don't, even when the deeper understanding is beautiful. If the hammer works when you hold it a certain way, that's great, but understanding all possible ways to hold a hammer doesn't always help get the nail in better.

Is it true? I mean, in mathematics having a proof of something is way stronger than having a conjecture. And in engineering, proving that your solution is optimal is way stronger than saying "hey look, I tried many things and finally it works!".

Worse, in statistics if you throw a bunch of tests and pick the one that "works" you might have false conclusions all the time. And AI is statistics.

Sure it works to test out 10 datatset and whatever number of different machine learning, but it takes time and money and might be suboptimal from an engineering POV.

logiduck• 2 years ago

Yes, this makes it very difficult to apply ML and RL in non-simulated scenarios.

With simulated scenarios you can just replay and "sweep" across hyperparameters to find the best one.

In a realworld scenario with limited information, fine tuning hyperparameters is much harder as you quickly find yourself in local maxima.

naveen99• 2 years ago

Similar:

Machine learning is still too hard for software engineers - https://news.ycombinator.com/item?id=30432987 - 151 comments

Machine learning is easier than it looks - https://news.ycombinator.com/item?id=6770785 167 comments

doctorM• 2 years ago

I'm a bit sceptical of the exponentially harder debugging claim.

First it looks polynomially harder for the given example :p.

Second other engineering domains arguably have additional dimensions which correspond to the machine learning ones mentioned in the article. The choice of which high level algorithm to implement is another dimension to traditional software engineering that seemingly exists and corresponds to the model dimension. This is often codified as 'design'.

The data dimension often exists as well in standard learning software engineering. [Think of a system that is 'downstream' of other].

It's probably a lot simpler to deal with these dimensions in standard software engineering - but then this is what makes machine learning harder, not that there are simply 'more dimensions'.

The delayed debugging cycles point seems a lot more valid.

pizzaknife• 2 years ago

i would subscribe to your newsletter if you offered one.

jolt42• 2 years ago

The article also pretends that there is only one correct answer, which seems atypical of the domain. The 1 green spot should extend somewhat fuzzily in each dimension in the ML case.

janalsncm5• 2 years ago

There isn’t only one correct answer. Quite the opposite actually, many configurations give you local maximas. The difficulty is that it can be hard to explain from first principles why one local maxima is good.

grantpitt• 2 years ago

I had similar thoughts on this. It looks polynomial because he classified errors into certain groups and spread them across an axis which we implicitly think is a dimension. But it's not... as he says, "Along any one dimension we might have a combination of issues (i.e. multiple implementation bugs)". So looking at the grid and thinking you're at a single point is wrong... but so is thinking you could be any configuration of locations (you couldn't be at points (1, 1) and (2, 2), you also need to be at points (1, 2) and (2, 1), i.e. the set of points you're at is transitive). Thus this is a bad way to "enumerate the failure cases" and makes his notion of "adding a dimension" pretty unintuitive. It makes more sense to see every point of his dimensions as itself a dimension. Each of these dimensions could be either correct or incorrect, 1 or 0. So you're configuration could be visualized as a string of 1's and 0's. Thus, the number of possible configurations grows exponentially (2^n).

PaulHoule2• 2 years ago

The #1 thing that makes it ‘hard’ in real life is that nobody wants to make training and test sets. So we have 50,000 papers on the NIST digits but no insight into ‘would this work for a different problem?’ (Ironically the latter might have been exactly what academics would have needed to understand why these algorithms work!)

ramesh31• 2 years ago

Would there be enough of a financial incentive to do so? Seems like a prime startup opportunity.

rzzzz• 2 years ago

I believe that Scale.ai was founded to do exactly this.

Buttons840• 2 years ago

I was just thinking the same, but I'm skeptical.

When researchers want to publish a paper, are they going to pay extra money for extra difficulty in publishing their paper? No, they'll just use whatever toy environment is free or already established and get that paper published!

MichaelRo• 2 years ago

> Seems like a prime startup opportunity.

Sometimes it's just ... hard. Apply some thought maybe before blindly parroting "profit!"

Reporter: "Why is it hard to cure cancer?". Crowd: "Would there be enough of a financial incentive to do so? Seems like a prime startup opportunity!"

Reporter: "Why is it hard to end World poverty?". Crowd: "Would there be enough of a financial incentive to do so? Seems like a prime startup opportunity!"

Reporter: "Why is it hard to build a warp engine?". Crowd: "Would there be enough of a financial incentive to do so? Seems like a prime startup opportunity!"

Reporter: "Why is it hard to wipe your ass using the left hand?". Crowd: "Would there be enough of a financial incentive to do so? Seems like a prime startup opportunity!"

You get the idea...

Mltrw2• 2 years ago

There is plenty of money in it but you need to sell b2b and tp enterprise. That is not fun and as such no one is doing it.

Put another way,if I were trying to do a start up in this space I'd spend 50% of my budget on marketing 25% on a third world data labelling sweatshop, 20% on data pipeline engineering and 5% on sexy ml stuff.

whiplash451• 2 years ago

You’re not paying tribute to MNIST-1D and many other datasets (including the massive segmentation dataset released by Meta with SAM). Read the literature before lecturing the community.

Mltrw2• 2 years ago

We still don't have enough data and people are still wasting their time with trying to extend algorithms instead of making better training data.

I've worked on a dozen ml projects two of them before Alex net came out and I've never gone wrong by spending 80% of my time creating a dataset specific to the problem and then using whatever algorithm is top dog right now.

Labelled data is king.

beckhamc• 2 years ago

The issue is the obsession with benchmark datasets and their flaky evaluation

graphe• 2 years ago

What else could you do to test it besides it works for me and this test said it's good at talking?

mistrial92• 2 years ago

no, this is routinely cited in introductory remarks these days, but ignores some practical aspects of the competitive context, among other things.

posterboy• 2 years ago

what is "this"?

Cacti3• 2 years ago

there are uncountable sets all over the place, and in practical terms, the repl loop may have a week long training lag after you hit enter.

also, the data is almost always complete shit.

lol. there’s no mystery why it’s hard.

phkahler• 2 years ago

> It becomes essential to build an intuition for where something went wrong based on the signals available.

This has always been my approach. I learned programming way before I had access to debuggers and other methods to dig in, set breakpoints and step through code to see where it was going wrong. As a result, when I got in the real world I kind of looked down on people using those tools (mostly because I hate tools actually). But then I saw people get to the root of problems that I don't think I ever could have solved, and I started to appreciate those tools and the detail you could get to. My preference is still to have a great understanding of how algorithms work, how the code is written, and what the problem is, and noodle out what and where things may be going wrong. I only switch to detailed monitoring of the insides when "thinking about it" fails. Maybe I should have gone into this ML stuff ;-)

Xcelerate• 2 years ago

With regard to model selection, one thing I learned a long time ago that provides powerful intuitive guidance on which model to use is the question: "How could this be compressed further?"

There are some deep connections between data compression and generalized learning, both at the statistical level and even lower at the algorithmic level (see Solomonoff induction).

For a specific example at the statistical level, suppose you fit a linear trendline to some data points using OLS. Now compute the standard deviation of the residual terms for each data point, and using the CDF of the normal distribution, for each residual, map its value into the interval [0, 1]. Sum together the logarithms of the trendline coefficients, the standard deviation, and the normalized residuals. This value is approximately proportional to "sizeof(data | model) + sizeof(model)". It represents how well you compressed the data using the OLS model.

But now suppose you plot the distribution of the residuals and find out that they do not in fact resemble a Gaussian distribution. This is a problem because our model assumed the error terms were distributed normally, and since this is not the case, our compression is suboptimal.

So you back out some function f that closely maps between the uniform distribution on [0, 1] and the distribution that the residuals form and use this f to define a new model: yᵢ = m*xᵢ + b + εᵢ, with εᵢ distributed according to f(x;Θ), Θ being a parameter vector. When you sum the logarithms again, you will find that the new total is smaller than the original total obtained using OLS. The new trend line coefficients will slightly mess up the residual distribution again, so iterate on this process until you've converged on stable values for m, b, and Θ.

At the algorithmic level, the recommendation to use compression as a model selection guide applies even to LLMs, but it's a bit harder to use in practice because "sizeof(data | model) + sizeof(model)" isn't the entire story here. Suppose you had a "perfect" language model. In this case, you would achieve minimization of K(data | training data), where K is Kolmogorov complexity. In practice, what is being minimized with each new LLM version is "sizeof(data | LLM model) + sizeof(training data | LLM model) + sizeof(LLM model)". You can assume "sizeof(LLM model)" is the smallest Turing machine equivalent to the LLM program.

sfink• 2 years ago

This article annoyed me. Not because I think it overestimates any of the difficulties, but it condescendingly compares against "standard software engineers" as if their problems are so much easier and lack additional dimensions beyond algorithm and implementation. It doesn't help that they call N^4 "exponential".

Long debugging cycles are not new. In fact, the field started out that way, when computers were slow enough that even a single edit-compile-run cycle could take hours (or days and some political capital, if you go back far enough). Even today, long debugging cycles are far from being restricted to ML, especially for failures that are only seen intermittently and in production.

Performance mattering is not unique to ML. Obviously.

Data issues are not unique to ML. Anytime you need to run against a "representative workload", you'll bump into them. Heck, anytime you run against a large test suite you'll run into issues with the quality of the comparison data, especially if the tests are long in the tooth. Furthermore, anything you're doing statistics on in general is going to bump into data issues—unless doing statistics is automatically ML?

ML lacks various other dimensions of difficulty. Distributed systems. Web browsers that need to execute arbitrary code that hasn't been written yet. Backwards compatibility. Forwards compatibility. In-production databases. Cross platform development. Power usage optimization. Concurrency (ML can have this, but it doesn't always need to, and it can be in the "embarrassingly parallel" bucket). Deep dependency graphs.

The author thinks ML development is hard because that's what they work on. They are but a grasshopper.

sackfield• 2 years ago

I think a big difference between ML and regular programming is how the components at scale make the systems viable. When I was learning computer science, it seemed quite intuitive to me that you would start out with assembly, then go to a C like compiler, then abstract that to a JIT/dynamic type language, and go from that to the UI. I could see how each step in the layer added value and presented its tradeoffs.

Contrast that to ML and even though I have done a large amount of work in it (in both university and in industry), I still can't fully appreciate how the building blocks interact to form an entire system. I find that I use intuition from other systems I have read about or implemented (e.g. decision trees and tabular data, ReLUs and images) to reason about the results in new systems and guess at better configurations and architectures.

Might say more about me, but I always found ML was a "start big and go backwards" deal whereas computer science was a "start small and go forwards" deal.

barelyauser2• 2 years ago

When building models it is useful to spend some time finding out what you already know about the problem. Things you yet don't know you know. This kind of knowledge will greatly simplify the model.

I see newcomers making this mistake very often. In industrial vision, for example, the newcomers like to create very complicated models. I then show them that the "box" you trained a entire model to recognize will actually always be there in this position for the camera, because it sits in a conveyor belt which restricts its lateral movement. The problem can simply be solved with simple image processing. Stuff like that happens all the time.

Cacti3• 2 years ago

You let newcomers dick around for months with a net on an industrial vision problem? This stuff was solved two decades ago. Why didn’t you just tell them?

shostack• 2 years ago

When I was working on a pet project to teach myself how to build a scoring model based on analysis of images on mobile I went down a whole rabbit hole on how to detect where the image is in a photo to draw a box around it and then compress to 500x500.

In reality, if I'm using a phone,I can just create a square frame for the user to center the image in and then compress.

Sometimes the simplest solution is the one you don't get to till after you slog through the harder approach. I'm glad I learned a bit about image processing with Pytorch along the way.

DeathArrow9• 2 years ago

I would start with a solid understanding of probabilities, statistics, calculus.

Aunche• 2 years ago

I don't think machine learning is particularly hard. It just involves a lot of brute force work and most of the time, you get a middling result that isn't particularly exciting. One of my friends had no CS background whatsoever but managed to make a basic Runescape mining bot by manually labeling hundreds of the correct colored rocks. His account got banned after a couple days though.

adamnemecek• 2 years ago

It's harder because there are no unifying theories. The ones that exist are seriously lacking.

itissid• 2 years ago

Great teachers(if you can find them): Andrej Karpathy, Andrew Gelman & Ben Goodrich(Columbia), Subbarao Khambampati(ASU) to name a few I know of.

Go Where the hard problems are (or find someone who is doing it): If you don't have a good intuition where to get good problems to practice on for a pay, choose a place to work where a Data Scientist is not just building dashboards/analytics but the company/team relies on them for answer to questions like: "What goals should we set for the next half based on what you see"?

ML practitioner (read: use ML tech to do/debug X) different from ML Engineer (Read: Implement ML algorithm X e2e on data ) is different from Applied Statistician (think marketing sciences or powering experiments like A/B tests): All three areas of work in different areas of ML in one form or another. But make sure what you want to work in is clear in your head and your expectations from it.

A lot of ML/Stats can be not with big data and yet really intuitive: I would say look for a problem domain in social/life/pharma/eco/political/survey/edtech sciences. They are full of intuitive models that need to be explainable and are often debuggable. An example here is usage of Stan software for Multilevel/Heirarchical Regression problems. Training here also makes you a great DS.

yshvrdhn• 2 years ago

I think one of the issues is that fixing a problem is a lot harder in ML than in software engineering. You know that the model fails on this particular data point. If you have identified a bug in the code and wrote a fix did a pull request as long you are able to test the code for conditions you failed on you would have solved the problem. With modern ml especially with nueral nets as long as you don't have a way to spin up a data engine to track the problems you are facing and collect similar points you problem is not fixed.

nonethewiser• 2 years ago

Certainly resonates with me. When the problem is something like a list being the wrong shape or two lists not maintaining a parallel order its basically invisible unless you load the mental model of the code and think deeply about it. Not like you’re going to notice your list of length 2,340,383 should start with [0.12, 1.67, 0.66 instead of [0.412, 0.567, 0.23

pbh1012• 2 years ago

I remember running into a paper from Google circa 2017 IIRC discussing the maintainability issues with machine learning models but haven’t been able to track down since. Does anyone know which one this is and have a link?

hollerith• 2 years ago

https://research.google/pubs/machine-learning-the-high-inter...

roenxi• 2 years ago

Machine learning isn't comparable to software development. It is a statistical modelling exercise. This is like asking why advertising is hard - if a non-expert wades in to a different domain then they may find it has different challenges than what they are used to! This is just a specific case of the normal things that analysts routinely deal with.

The major challenges in this youthful field of machine learning are building appropriate hardware and making it work. That, so far, has kept it the domain of the software engineer. As the situation continues to stabilise this is going to become the playground of statisticians and analysts.

Or to put it another way - if you compare any field to software engineering, the problem is that other disciplines have a much harder time debugging things. Software is almost unique in that debugging is cheaper and quicker than building things right the first time.

p-e-w• 2 years ago

Machine learning isn't comparable to software development. It is a statistical modelling exercise.

It's neither of the two. Machine learning isn't comparable to any other human endeavor because in many cases, much more value comes out of the models than (seemingly) goes in.

LLMs for example are punching way above their weight. The ideas underlying their software implementations are extremely simple compared to the incredibly complex behavior they produce. Take some neural networks that can be explained to a bright high schooler, add a few more relatively basic ML concepts, then push an unfiltered dump of half the Internet into it, and suddenly you get a machine that talks like a human.

Obviously I'm simplifying here, but consider that state-of-the-art LLM architectures are still simple enough that they can be completely understood through a 10-hour online course, and can be implemented in a few hundred lines of PyTorch code. That's absolutely bananas considering that the end result is something that can write a poem about airplanes in the style of Beowulf.

eru4• 2 years ago

I'm not sure it's as simple as you make it sound.

Lots of problems have very simple solutions. And progress often means finding simpler solutions over time.

But coming up with those solutions, and debugging them, is what's hard.

For a comparison, have a look at how pistols got simpler over the last two hundred years. Have a look at the intricate mechanism of the P08 Luger https://www.youtube.com/watch?v=9adOzT_qMq0 and compare it to a modern pistol of your choice. (And the P08 Luger is already pretty late invention.)

Or have a look at modern Ikea furniture, which can be assembled and understood by untrained members of the general public. But designing new Ikea furniture is much harder.

wegfawefgawefg4• 2 years ago

I dont feel like im doing statistical modeling when i do ml. Usually feels more like pipe alignment, followed by tremendous amounts of debugging.

salty_biscuits• 2 years ago

That is also what statistical modelling feels like. EDA and data cleaning.

p1esk4• 2 years ago

It depends on what is it you do when you “do ml”.

laichzeit0• 2 years ago

The heuristic I use for distinguishing between statistical modelling, machine learning and AI is is through feature engineering and model specification:

- Statistical modelling: Manual feature engineering, manual model specification (y = ax + b)

- Machine learning: Manual feature engineering, automated model specification (y = ax + b or y = ax^2 + b, I don't care, the algorithm should figure it out).

- AI: Automated feature engineering (e.g. CNN), automated model specification

jvans• 2 years ago

Machine learning systems are hard because your system can be badly under performing but still doing objectively great. I've seen systems that produce amazing improvements in core business metrics and then years later some subtle bug in the labeling process is accidentally uncovered and fixing it boosts performance by an additional 20%.

A ton of time in ML is spent on minimizing the surface area for bugs because it can be difficult to even know they exist.

nerdponx2• 2 years ago

It's hard because there's rarely one single correct solution, design, answer, etc. It's hard in the same way as any other open-ended research work is hard. It will never not be hard in that sense.

4death4• 2 years ago

I used to work on an ML research team. In addition to what the author mentions, there is an entirely separate issue: whether or not what you're attempting to do is possible with the approach you've chosen. Consider making an iOS app. For the most part, an experienced software engineer can tell you if making a given app is possible, and they'll have a relatively clear idea about the steps required to realize the idea. Compare this to ML problems: you don't often know if your data or model selection can produce the results you want. On top of that, you don't know if you're not getting results because of a bug (i.e. the debugging issues mentioned by the author) or if because you have fundamental blocks elsewhere in the pipeline.

owlninja• 2 years ago

You nailed where I currently stand. At my company I've been a jack of all trades but mostly software/dba work. My boss and I were very excited about ML when the hype cycle was taking off several years ago and completed a successful project. Fast forward to today, I got loaned out to another team that lost their data scientist, and for the first time in my career I'm having to say - "I don't think we can do what you want." To me the "science" part really stands out. I have a decent grasp of methodologies and tools, but after weeks of dissecting the issue my conclusion is that they just don't have enough useful data...

throwaway8877• 2 years ago

The situation is not bad then. Can they collect more data? Can they generate more data?

jxramos• 2 years ago

It can be a very empirical art. If you can't generate more data at the time you can sometimes invest in reviewing the hand labeling ground truth to verify no false classifications slipped by.

j7ake• 2 years ago

This is where good simulations are useful. If you can show even in ideal simple data scenarios, you encounter inference problems, it’s a strong signal that real data has little chance of doing better.

In general these are model identifiability issues.

PeterisP• 2 years ago

Every data science team should have a wall decoration with John Tukey's quote "The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data."

steve_adams_86• 2 years ago

they just don't have enough useful data...

I'm not well-versed in this, or not as well as you are, but this has been my conclusion as well about a lot of ML project ideas from teams I've been on.

You need so much data to do useful things. Especially the magical kinds of things people tend to want to do. I think these types of datasets are on a scale most software developers typically don't see. Even with the data in hand, it's nothing like trivial to determine how to do something half-way useful with it.

MichaelZuo• 2 years ago

i.e. there a lot more unknown unknowns, which takes a lot more effort and intelligence to not stumble into haphazardly then most other fields.

raincole• 2 years ago

But aren't all science basically like this? If you know your hypothsis works before you do the experiments, it's not science anymore.

nerdponx2• 2 years ago

Yes, and science is "hard" compared to software development in a lot of ways. Less certainty of success and poorly defined success criteria.

bugglebeetle• 2 years ago

Not really. It’s easy to tell relative to existing methods whether the size of data will solve the problem. For example, if you’re trying to solve a classification problem with a large number of labels, but only have a small amount of training data for some (or all) of them, it will probably never work.

dylan6042• 2 years ago

Sometimes something you've done works, but you really don't know why/how. You then have to walk it back to figure out by experimenting what is causing it to work. I feel like this happen(ed|s) in chemistry a lot. Was it the fact that I stirred it counter clockwise this time, or that I got distracted and the temp went 5° hotter than intended, or that I didn't quite clean my beaker properly and some residue contaminated this batch, or any number of other steps.

eru4• 2 years ago

You are right. That's why you want to avoid doing science, when you can.

Ideally, you want to be solving engineering problems instead.

tbrownaw• 2 years ago

you don't often know if your data or model selection can produce the results you want.

Like, not knowing if your data set actually contains anything predictive of what you're trying to predict?

janalsncm5• 2 years ago

Here’s an example of something similar. Say you have a baseline model with an AUC of 0.8. There’s a cool feature you’d like to add. After a week or two of software engineering to add it, you get it into your pipeline.

AUC doesn’t budge. Is it because you added it in the wrong place? Is the feature too noisy? Is it because the feature is just a function of your existing features? Is it because your model isn’t big enough to learn the new feature? Is there a logical bug in your implementation?

All of these hypotheses will take on the order of days to check.

galaxyLogic• 2 years ago

The Farmer is Turkey's best friend. Turkey believes so because every day Farmer gives Turkey food, lots of food. Farmer also keeps the Turkey warm and safe from predators. Turkey predicts that the Farmer will keep on being his best friend also tomorrow. Until one day, around Thanksgiving, the prediction goes wrong, awfully wrong.

senthil_rajasek• 2 years ago

I have always thought of ML (not DL) as phenomena that can be modelled mathematically.

It turns out that not all problems have a great mathematical model like self driving cars for instance and so the search continues...

eru4• 2 years ago

Why would self-driving cars not have a great mathematical model?

Or do you mean that the models are either black boxes (like deep learning) that we don't understand, and the white box models are not good enough?

croutons• 2 years ago

All of ML, including DL, are literally implemented using mathematical models. Alas, a model is just a model and doesn’t imply it works well or imply that it’s simple or easily discoverable.

dylan6042• 2 years ago

I have the same sentiments about DIY electronic designs. If I take someone else's designs and build it at home, I know it's all on my build skills lacking if it doesn't work as there is already working examples. If I design a device from the electronics to the software, I don't know if the thing isn't working because of bugs in the code, problems with the build of the electronics, or fundamental flaw in the design itself. At least not without a ton of time debugging it all.

Animats• 2 years ago

However, we now have techniques for debugging electronics. Electronics tends to be designed to be decomposable into subunits, with some way to do unit testing. At least in the prototype, before it's shrunk for production. Test gear can be expensive, but it exists, all the way down to the wafer if needed.

That wasn't always the case. Electronics problems used to be more mysterious. The conquest of electronic design and debugging is what allows making really complex electronics that works. It really is amazing that smartphones work at all, with all those radios in that little case. That RF engineers can get a GPS receiver and a GSM transmitter to work a few centimeters apart is just amazing.

Machine learning isn't that far along yet. When it doesn't work, the tools for figuring out why are inadequate. It's not even clear yet if this is a technique problem which can be fixed with tooling, or an inherent problem with having a huge matrix of weights.

dchichkov2• 2 years ago

On top of that, vast majority of engineers and researchers who had joined the field, only did it in the last few years.

While, like with many other fields, it takes decades to get to a level of a well-rounded expert. One paper a day, one or two projects a year. It just takes time. No matter how brilliant or talented you are.

And then the research moves on. And more is different. A GFLOPS shift to TFLOPS and then PFLOPS over a single decade is a seismic shift.

3abiton• 2 years ago

I think one issue also, is that ML is so large as a field, it ecompasses huge subfields, or related fields (statistics, optimizatiob, etc...)

DeathArrow9• 2 years ago

whether or not what you're attempting to do is possible with the approach you've chosen

Knowing that depends on your level of understanding the field and the math behind and also experience. If you just know how to make API calls, then it's hard.

What would be problematic if you want to do sentiment analysis for some product reviews? Result is the public perception within a margin of error, you have your data, you know what you want, you know how to get there.

jurgenaut232• 2 years ago

Well, even with a high level of understanding, any sufficiently advanced use case will still have some uncertainty regarding its "feasibility". Of course, you might think that some problems are "solved", e.g., OCR, translation, (common) object recognition, but MANY other problems exist where, no matter how experienced and knowledgeable you are, you can only have an educated guess as to whether a given model can achieve a given performance without actually trying it out.

Where experience and knowledge really pays off is in telling apart model performance from bugs. There is a real know-how in troubleshooting ML pipelines and models in general.

mnky9800n• 2 years ago

Welcome to the last year of work for me. Now, I firmly believe what I set out to do cannot be done. However when I started, it seemed quite reasonable that the model I would build would be successful at it's purpose.

Sohcahtoa82• 2 years ago

In addition to what the author mentions, there is an entirely separate issue: whether or not what you're attempting to do is possible with the approach you've chosen.

I had a fun project I tried once. I wanted to see if a neural network could be fed a Bitcoin public key and output the private key. To make things simple, I tried to see if it could even predict a single bit of the private key. 256 bits of input, 1 bit of output.

I created a set of 1000 public/private key pairs to act as the test set. Then, I looped, generating a new set of 1000 key pairs, trained for several epochs, then tested on the test set.

After 3 days of training (granted, on a CPU several years ago), the results on the test set did not converge. Nearly every trial on the test set was 47-53% correct. I think I had one run that was 60% correct, but that was likely pure lock. Do enough trials of 1000 coin flips and you'll likely find one where you get at least 600 heads.

Back to your original comment...Is what I was attempting to do even possible? Did my network need more layers? More nodes per layer? Or was it simply not possible?

Based on what I know about cryptography, it shouldn't be possible. A friend of mine said that for a basic feed-forward neural network to solve a problem, the problem has to be solvable via a massive polynomial that the training will suss out. Hashing does not have such a polynomial, or it would indicate the algorithm is broken.

But I still always wonder...what if I had a bigger network...

epgui• 2 years ago

I find it difficult to buy the argument that “it’s not difficult because of the math”, at least in the way the author meant.

I do however literally agree with the author: ML is not difficult because of the math. It’s difficult because for some reason people think the math is not important. But ML is math.

DeathArrow9• 2 years ago

ML without math is like trying to play 5th Symphony without knowing notes, chords or any musical theory.

hooande• 2 years ago

Debugging is a problem. But the real problem I'm seeing is our expectations as software developers. We're used to being able to fix any problem that we see. If a div is misaligned or a column of numbers is wrong we can open the file, find the offending lines of code and FIX it.

Machine learning is different because every implementation has a known error rate. If your application has a measured 80% accuracy then 20% of cases WILL have an error. You don't know which 20% and you don't get to choose. There's no way to notice a problem and immediately fix it, like you can with almost every other kind of engineering. At best you can expand your dataset, incorporate new models, fix actual bugs in the code. Doing those things could increase the accuracy up to, say, 85%. This means there will be fewer errors overall, but the one that you happened to notice may or may not still be there. There's no way to directly intervene.

I see a lot of people who are new to the field struggle with this. There are many ways to improve models and handle edge cases. But not being able to fix a problem that's in front of you takes some getting used to.

crotchfire• 2 years ago

To be fair, chip design has both of these problems to a much greater degree than machine learning:

- Exponentially Difficult Debugging

- Delayed Debugging Cycles

nnevatie• 2 years ago

I found the explanation quite convoluted (pun intended). Any system with billions of parameters is bound to be difficult to reason about.

nazka• 2 years ago

For me it’s 2 things: math is already hard even with a teacher and after you found a job it’s just you and your screen. The other part is research moves at a crazy speed it’s very hard to keep up I think while having a job.

DeathArrow9• 2 years ago

What do we even mean by "Machine Learning"?

Understanding ML algorithms and the math behind, being able to change the algorithms and devise new ones?

Using some ML libraries and frameworks?

Taking an implemented solution and training it and fine tuning parameters?

DeathArrow9• 2 years ago

As with everything, if you don't know the fundamentals, the basics, you are very limited on what you can achieve and find stuff difficult.

To use a parallel from software if you just know a programming language, how to call libraries and APIs you can't compare to a guy with a solid CS background who also understands algorithms, data structures, complexity, math and knows how computers work down to NAND gates.

Because I have studied some ML fundamentals during my batchelor and master degrees I know I am not competent in ML and AI. But I know how to become competent if I need or want to. Most people do believe finishing a bootcamp and calling some frameworks in Python makes them competent.

jurgenaut232• 2 years ago

Yes, bootcamps are really a great way to score high on the Dunning-Kruger score, but not so much on any other metric of value. You need lots of sweat and tears to become a capable and competent ML engineer, especially to tell apart intrinsic limitations (i.e., no signal in your data) vs extrinsic issues (e.g., a bug anywhere between ETL and prediction, or a methodological mistake).

kick_in_the_dor• 2 years ago

and knows how computers work down to NAND gates.

I lol'd

DeathArrow9• 2 years ago

I don't think ML is harder than other technical and scientific fields. Being a good software developer, a good software scientist, a good mathematician, a good astronomer, a good physicist is hard.

And of course, there are hard fields outside of science. Being good at any kind of art is hard.

Just because some people believe they are good at something (because Dunning Krueger effect) doesn't mean that field is easier than ML. They assume ML is harder because they happen to know a few bits in a particular field and nothing about ML. Then, the same kind of people will learn some superficial bits on ML and think it's easy.

Any human endeavor done properly means time, sweat, critical thinking, determination. And lots of it.

DeathArrow9• 2 years ago

Let's draw a paralel. It's algebra hard? No if you want to solve simple equations. Yes if you want to achieve masters hip.

feverzsj• 2 years ago

It's not hard. It just doesn't work. It's modern alchemy.

jokoon• 2 years ago

Unless computer scientist really try to understand how actual brain build their networks, I don't think ML will really bring real advances.

Computer science is pointless when it's not applied to another field of science.

mvkel• 2 years ago

This is a dumb question: could we not make an ML debugger out of ML?

It seems ML, or at least model training and fine tuning, is all about pattern recognition.

Could the same thing not be done where a model is trained on ML algos running correctly vs. not and it performs the pattern recognition (i.e. intuition) to find the root cause?

swingingFlyFish• 2 years ago

" Engineers specializing in machine learning continue to command a salary premium in the job market over standard software engineers"

I still haven't really seen this. Data Scientist still seem to make about the same as an experienced Backend Engineer.

Why is machine learning 'hard'? (2016)

Related Stories