I personally think it is much more important to have strong statistical intuitions rather than intuitions about what neural networks are doing.
The latter isn’t wrong or useless. It’s simply not something a typical software engineer will need.
On the other hand, wiring up LLMs into an application is very popular and may be an engineer’s first experience with systems that are fundamentally chaotic. Knowing the difference between precision and recall and when you care about them will get you a lot more bang for your buck.
I would suggest the gateway drug into ML for most engineers is something like: we have a task and it can currently be done for X dollars. But maybe we can do it for a tenth of the price with a different API call. Or maybe there’s something on Huggingface that does the same thing for a fixed hourly cost, hundreds of times cheaper in practice.
I'm just trying to develop the lens where I can see a problem and know what properties of it are meaningful from an ML standpoint.
Coming from a specific domain where I have a sharpened instinct for how things are haven't really given me the ability to decompose the problem using ML primitives. That's what I'm working on.
Just read a good textbook instead of this LLM-written stuff. For example those by Murphy or Prince or Bishop. Or one of many YouTube lecture series from MIT or Stanford. There are many primer 101 tutorials and Medium posts. But if you actually want to learn instead of procrastinating, pick up a real textbook or work through a course.
I've bounced off of many good textbooks. Even Karpathy's YouTube series was too dense for me. I'm trying to come in at a more palatable level.
This was a two day exploration where I provided the syllabus and ran through it with Claude Code, asking questions, trying to anchor it to stuff I understand well. I feel like the artifact has value.
This is my weekend project. I am building up my pattern recognition in machine learning. By that I mean see X problem, instantly think of Y solution. The primer markdown file is the artifact of that exploration.
read it from top to bottom or better have your favorite language model read it and then explore the space with a strong guided syllabus.
Framing a business problem in terms of ML is indeed important. Where does classification come in, where does regression come in, when to use retrieval, when to use generative solutions. Would be a good section to add imo.
The latter isn’t wrong or useless. It’s simply not something a typical software engineer will need.
On the other hand, wiring up LLMs into an application is very popular and may be an engineer’s first experience with systems that are fundamentally chaotic. Knowing the difference between precision and recall and when you care about them will get you a lot more bang for your buck.
I would suggest the gateway drug into ML for most engineers is something like: we have a task and it can currently be done for X dollars. But maybe we can do it for a tenth of the price with a different API call. Or maybe there’s something on Huggingface that does the same thing for a fixed hourly cost, hundreds of times cheaper in practice.
Coming from a specific domain where I have a sharpened instinct for how things are haven't really given me the ability to decompose the problem using ML primitives. That's what I'm working on.
This was a two day exploration where I provided the syllabus and ran through it with Claude Code, asking questions, trying to anchor it to stuff I understand well. I feel like the artifact has value.
read it from top to bottom or better have your favorite language model read it and then explore the space with a strong guided syllabus.