r/learnmachinelearning

Hello Folks,

When I started teaching my free online lectures, on Machine Learning, the intent was to help learners understand the topics of Machine Learning in a simple and digestible manner.

When I was a first time learner, started my grad program, books as Probabilistic Machine Learning by Murphy, Bishop, were told to us as excellent text books for Machine Learning, yet seemed always very difficult to read and understand.

To work around that, I started making content based on these foundational textbooks. We covered Introductory concepts, Probabilities and Statistics.

Slowly I started understanding, that the difficulty is faced not just by me, but all the learners. Hence the need.

I do hope that learners will see the importance of core foundational concepts, which are the pillars for modern machine learning, and Probabilistic Machine Learning is that core pillar, without which ML always seemed to me to be some blackbox.

Link: https://youtube.com/@aayushsugandh4036

Hi everyone,

I’ve mainly been focused on full-stack development throughout the first few years of my degree. Now that I’m in my 3rd year, I’ve started thinking more seriously about my long-term direction, and I’m becoming much more interested in machine learning and research.

My goal isn’t just to learn how to use ML libraries. I’d eventually like to understand the fundamentals well enough to read research papers, do my own research, and potentially pursue a research-focused master’s/PhD.

Right now, I’m planning to study these three DeepLearning.AI programs:

1. Mathematics for Machine Learning and Data Science
2. Machine Learning Specialization
3. Deep Learning Specialization

The math specialization covers linear algebra, calculus, probability, and statistics, while the ML specialization focuses on foundational ML algorithms and practical implementation.

My question is:

Is this a good learning path if my long-term goal is ML research?

What would you recommend I add or change?

For example:

• Should I study more mathematics beyond these courses?
• Should I learn statistics more deeply?
• Should I learn PyTorch, NumPy, etc. separately?
• When should I start reading research papers?
• Should I work on Kaggle/projects before trying research?
• Are there any textbooks or university courses (Stanford/MIT/etc.) that you would strongly recommend?
• Should I specialize in an area such as NLP, computer vision, or something else?

I’d really appreciate advice from people who have gone through a similar transition from software/full-stack development → machine learning → research.

Thanks!

Conclusion: Thanks for the comments, everyone has been so helpful and generous with the suggestions. I realized that I did not asked my question properly and my main problem went unseen... (Well I'm at fault by opening the conversation by Is there a "TypeScript for Python"?).
I will create a new post with the right problem statement, but let me thank u/ProsodySpeaks, and u/JamzTyson which gave me idea on what to do next.

Cheers!

Hi, sorry for the basic question. I'm coming from strongly/statically typed languages (Kotlin, Go, Rust, etc.), and I was aware that Python is dynamically typed, but given how popular Python is, I expected its typing utilities (type hints + static type checkers) to provide something closer to TypeScript.

I'm working on an ml framework where the main interface has to be Python, and I ran into a magnitude of problem I was not expecting...

Requirements:

• Type checking before a pipeline runs (no values exists yet, just type hints/annotations)
• Type checking during the pipeline run (value and type hints/annotation should match)
• The type hints are used to decide if pipeline components are compatible (similar to LangChain or similar frameworks)
• Require as little setup as possible, so even junior engineers can use the framework safely.

I spent some time trying to implement this using Python's existing typing mechanisms. A few thousand lines of code later, I ended up with a type checker for my specific pipeline system:

https://github.com/trained-by-humans/ml-pipes/blob/main/packages/core/src/ml_pipes/validation.py

And my own type checking utilities:

https://github.com/trained-by-humans/ml-pipes/blob/main/packages/core/src/ml_pipes/_typing/annotation.py

But now I'm wondering:

Am I going way too far here? Is there a much more idiomatic Python approach that I'm completely missing?

And just to be clear: this is only the pre-run check so far. Runtime type checking doesn't exist yet.

Update1: Thanks for highlighting Pydantic, I've considered to use it for runtime since it covers enforcing type hint/annotation on values.

Update2: The TS or other "typing languages", would essentially help with highlighting the compatibility, they answers questions like is input of type A is assignable to parameter of type B, which is very very important for pipeline validation before running the pipeline.

Update3: The type of type checking I need is this, imagine a pipeline like this:

Pipeline([
    Resize((640, 640)),
    Store("resize_transform", source=1),
    Pick(0),
    Normalize(),
    Infer(model_path),
    Extract("output0", as_="preds"),
    Squeeze("preds"),
    Transpose("preds"),
    Slice("preds", slice(None, 4), as_="boxes"),
    Slice("preds", slice(4, None), as_="scores"),
    ArgMax("scores", as_="classes"),
    GatherRows("scores", "classes"),
    ConvertBoxFormat(from_="cxcywh"),
    NMS(conf_threshold=conf_threshold),
    Recall("resize_transform"),
    ProjectBoxes(),
    ToDetections(),
])

I need to make sure the upstream operator output is compatible with downstream input. You can find out more about it in the page (Validation.md under the operator compatibility section)

Please save me from implementing another few thousand lines of code. 😭

We retrained Wolf Defender.

The main reason was not that attack detection was bad. The bigger issue was false positives.

The previous models were already good at detecting prompt injections, but especially on short benign inputs, security-related text, code snippets or ordinary conversations they could still be too aggressive. We also got a few reports from users that made this pretty obvious.

One example was just:

“Who are you?”

Wolf Defender Small previously classified this as a prompt injection with around 94% confidence.

For v2 we therefore changed the training setup quite a bit. Both Wolf Defender and Wolf Defender Small were retrained from fresh mmBERT checkpoints, with a much stronger focus on hard negatives.

That includes short conversations, emails, documentation about prompt injections, benign policy and system language, code and configuration snippets and generally inputs that contain words or structures which look suspicious without actually trying to manipulate a model.

We also added more counterfactual samples, multilingual examples, adversarial obfuscations and long-context injections at different positions in a document. Training combines short 256-token samples with full 2,048-token windows and uses supervised contrastive regularization, FreeLB adversarial training and Smooth-Max aggregation for long documents.

The main change can be seen in the benign benchmarks:

Model	Benchmark	v1	v2
Wolf Defender	Hard benign specificity	81.57%	96.23%
Wolf Defender	Real-world benign specificity	66.85%	96.63%
Wolf Defender Small	Hard benign specificity	82.12%	96.67%
Wolf Defender Small	Real-world benign specificity	73.60%	94.38%

At the same time, attack detection stayed roughly where we wanted it:

Model	Qualifire F1	Jayavibhav F1
Wolf Defender	95.14%	97.84%
Wolf Defender Small	95.21%	97.68%

There is also a tradeoff here. Some of the very high scores on our cleaner validation distributions went down slightly.

For us that is fine.

A security classifier with near-perfect benchmark scores is not very useful if normal traffic gets blocked all the time. We would rather lose a small amount on an easier validation set and get substantially better behavior on actual benign inputs.

The “Who are you?” example now gets classified as benign by Wolf Defender Small v2 with 98.55% confidence. A real instruction-override attempt is still detected as an injection with 99.99%.

We also updated the deployment variants. Both models are available as regular Transformers checkpoints and as ONNX exports in FP32, FP16, mixed INT8/FP16 and INT8 with INT4 embeddings.

The smallest Wolf Defender Small artifact is now 96 MB.

More details, benchmarks and model files are here:

https://huggingface.co/patronus-studio/wolf-defender-prompt-injection

https://huggingface.co/patronus-studio/wolf-defender-prompt-injection-small

If anyone is running prompt-injection classifiers on real traffic, I’d also be interested in which benign inputs still cause the most false positives for you.

I'm a first-year Computer Engineering student, and I've been learning about machine learning and CNNs recently.

As a learning exercise, I built a small sketch classifier from scratch in C++17, without using PyTorch/TensorFlow. It implements the CNN, backpropagation, gradient checking, SGD, etc., and currently gets around 94% validation accuracy.

GitHub: https://github.com/rituuu001/Doodle-guesser

Now I'm stuck on what I should do next.

I could keep improving this project — better training, data augmentation, a deeper CNN, more classes, etc. But I'm wondering if that's actually the best use of my time, or if I should consider this project "done" and start something completely different.

For people who have more experience with ML:

How do you decide when a project has taught you enough and it's time to move on?

Would you recommend:

• continuing to improve this project until I've explored it more deeply, or
• moving on to a new ML project where I can learn something different?

I'm mainly trying to avoid spending months endlessly polishing the same beginner project, but I also don't want to move on too quickly without getting enough out of it.

Would really appreciate some honest advice.

Hey everyone!

I'm a data scientist and I've been pretty fascinated by reinforcement learning for a while. A few days ago my friends showed me Pokelike, a small Pokémon roguelike that runs in the browser. The first thing I thought was that it could be pretty fun to turn it into an RL environment.

So I did.

The repo is here:

https://github.com/pierpierpy/pokelike.xyz.bot

The idea is to run the actual game locally and expose its state and actions to an agent. There is no image processing involved. The bot gets the game state directly and decides what to do next. The agent has to make the decisions around the battles, like where to go on the map, which Pokémon to catch, which items to take, when to swap Pokémon and which moves to learn.

One thing I found interesting is that the map forces you to make some decisions quite early. Once you choose a node, the other nodes on that layer are gone, so deciding where to go can matter quite a bit later in the run. There is also a lot of information in the state that could potentially be useful, but I'm still not sure what the best way to represent it is.

I've already implemented a few basic RL agents. There is currently a Dyna-Q agent and two linear SARSA agents in the repo. The results are not amazing yet. On the current benchmark, random gets around 0.56 badges, Dyna-Q gets around 0.62, while the two SARSA agents get around 1.30 and 1.36. The two SARSA agents mainly differ in their state representation, with the better one using 100 hand-designed features instead of 81.

This is probably the part I'm most interested in at the moment. Finding a good state representation seems to make a pretty big difference, and the environment has some properties that make it a bit more interesting than I initially expected. The reward is fairly sparse, the action space depends on the current state, and some decisions only become useful several steps later.

At the same time, the environment is completely reproducible. With the same seed and the same actions you get exactly the same run. For the current leaderboard I'm using 50 fixed seeds, so different agents can be compared on the same games.

The interface is also intentionally pretty simple. You can basically implement a bot that takes the current state and returns an action. It doesn't have to be a specific RL algorithm either. You could try DQN, PPO, search, a hand-written policy, or pretty much anything else.

I'm still experimenting with the environment and the agents, so I'd be really curious to see what other people would try. In particular I'd love to see if someone can get significantly better results with a better state representation or a different reward function.

you can experiment with the environment with no efforts, just follow the guide and readme, setup the enrinvonment, experiment a bit and then if you like the result, you can create a pull request to the repo with your bot in the bots/ folder (everything is clearly explained in the GUIDE.md)

If you want to try it, everything is in the repo

https://github.com/pierpierpy/pokelike.xyz.bot

If you find bugs or have ideas for the environment, please let me know. I'm happy to make changes if there are things that would make it more useful for experimenting with RL.

The whole thing also runs offline. During setup it downloads the game and the required assets, and after that everything runs locally.

I originally started this because I thought it would be a fun little RL project, so I'm mostly curious to see how far people can push it.

I went to bed with a fine-tune running. Woke up eight hours later to a loss that had been NaN since step 300 — the whole night of GPU time gone, and nothing had told me. If you fine-tune, you've lived some version of this: the run that trained at learning-rate-zero the entire time, or quietly ate a dataset with 40 broken rows, and you only find out at the end.

So I built a deterministic linter for training runs — trainproof (pip install trainproof, MIT) — and then I spent days trying to prove it wrong.

One Qwen2.5-3B QLoRA, run five times: once clean, four times with exactly one thing sabotaged. Four it caught instantly. One fooled it completely — and that one taught me the most.

It wasn't the NaN run. It wasn't the fp16 overflow. It wasn't the learning rate cranked 100× too high (that spiked the gradient norm to 2650× the median — caught in seconds).

It was shuffled labels. Pure garbage — a dataset that literally cannot be learned.

That run reduced its loss by 62%. On the curve it looked like textbook-healthy training. It was learning absolutely nothing — just memorizing the statistics of noise, which any network will happily do. From its own loss curve it is indistinguishable from a real run. No single-run, loss-only rule can catch it. So instead of pretending my tool is magic, I wrote that limitation straight into the README — and added a compare mode, because the failure is visible the moment you put it next to a known-good run.

That's the whole philosophy: no ML judging ML, no "87%-confidence" scores. Every check is a deterministic rule that either fires or doesn't, and every finding cites the exact numbers behind it. When it can't be sure, it says so instead of guessing.

Across a run's life:

• Before a single GPU-second — lints the dataset + tokenizer (malformed JSONL with the line number, empty rows, duplicates, missing eos_token, pad==eos, over-length samples). Exits non-zero → straight into CI.
• During training — one-line HuggingFace callback. Warns by default; flip on stop_on_fail and it aborts a doomed run itself. In testing it killed a diverging run at step 20 of 300 — 93% of the scheduled steps never ran.
• After — reads the log: diverged / flatlined / NaN'd / spiked.
• vs a baseline — the ratio rules that catch the shuffled-labels case.

All five sabotaged runs' real logs ship in the repo (examples/gallery/) with a 15-run / 3-seed evidence matrix — reproduce every verdict yourself. Reads plain logs (HF trainer_state.json, Coqui, JSONL/CSV), doesn't import torch.

Repo: https://github.com/Mormolykos/trainproof · pip install trainproof

Honest question: what's burned your GPU hours? If a deterministic check would've saved you, tell me — it goes in, with credit.

Been working on a visualisation engine for PyTorch tensors.

When I was learning PyTorch, tensors really started to click once I stopped thinking of them as arrays and started thinking of them more like Lego blocks — things you can slice, reshape, stack, repeat, squeeze, and combine.

So I built a visualisation library to make those operations tangible.

Write a PyTorch operation and actually see what it does to the tensor.

A huge amount of machine learning ultimately comes down to manipulating tensors. Once you can build an intuition for their shape and how operations transform them, a lot of PyTorch starts to feel much less abstract.

Would love to hear whether something like this would have helped when you were learning PyTorch and if you'd like me to open source this :)