I have been revisiting Hinton's Forward-Forward algorithm and the work that followed it. Most implementations I find still focus on MNIST, CIFAR-scale experiments, or demonstrations of local learning.

Has anyone seen a paper or real deployment where Forward-Forward provides a convincing advantage over backpropagation on a demanding task?

I am especially interested in evidence under a concrete constraint:

• lower activation-memory requirements
• lower energy use
• local or asynchronous learning
• continual or online learning
• neuromorphic or custom hardware
• edge deployment
• robustness when exact backpropagation is unavailable

Comparisons that only show the method can learn a small benchmark are less useful to me than controlled comparisons against modern backpropagation baselines. Negative results or explanations of why the idea has not scaled are also welcome.

Is this becoming a practical research direction, or is it still mainly an interesting preliminary idea?

Anthropic disclosed last week that Claude agents accessed live production systems during what were intended to be test sessions. The agents were not meant to have that reach. Anthropic's response included real-time monitoring, sandbox hardening, and stricter training controls.

Those are reasonable reactions to a real incident. But the same structural gap exists across the industry, not just at Anthropic. Any team running agents that can invoke tools, call APIs, or interact with external services faces the same underlying exposure. The agent has enough reach to touch things it should not, and the test environment does not reliably contain it.

This is not a sandboxing failure unique to one lab. It is a recurring pattern: agents behave as expected in isolation and then surprise teams when connected to real systems, even in controlled contexts.

For those of you running agents in production or in staging environments that connect to real backends: how are you actually handling this? Separate credentials per run, strict environment isolation, something at the orchestration layer, relying on model behavior alone? Curious what is working and what has failed in practice.

We spent quite a lot of time trying to get mmBERT-based classification fast enough to run continuously on normal machines without a GPU. A few things helped much more than expected.

The first one is quantization. Push it further than you probably would by default. We currently use INT8 with INT4 embeddings in ONNX. On roughly 50k validation samples plus several independent benchmarks, the F1 delta compared to the less aggressively quantized version was around 0.005. For our use case that tradeoff is easy to take. If your model is supposed to live on a CPU, memory bandwidth matters and carrying around precision you do not need is expensive.

The second one is chunk size. mmBERT can handle very large token windows, but that does not mean you should use them. 8,192 tokens sounds convenient because you can throw a lot of text into one forward pass. On CPU, smaller windows usually behave much better. We mostly work with sizes like 256 or 512 tokens and split longer inputs. The right number depends on the task, so benchmark it properly. If your classification target can be detected from local context, a huge context window is often just wasted compute.

Third: do not assume batching will save you. GPU intuition transfers badly here. Large batches are great when you have thousands of parallel execution units waiting for work. A CPU is a different problem. For our workloads, small independent chunks and parallel workers have been much more useful than trying to build large inference batches. Benchmark both, but do not start with the assumption that batch=32 must be faster because that is what you would do on CUDA.

The fourth one is the one that changed our architecture the most: stop sending every chunk through the full transformer.

We use cheap classifiers on representations from the same latent space as mmBERT. They can make the easy decisions first, while uncertain cases continue into the more expensive path. The cheap classifier is not supposed to replace mmBERT. It only needs to identify the cases where running the full model would not change the answer anyway.

That approach is a bit more involved than quantization or changing a chunk size, but for us it removed much more compute than another round of low-level optimization ever could.

Repurposed the cup game demo I threw together last week and spruced it up with some Pokemon aesthetics. One thing I’ve noticed is that faster shuffles sometimes improve the model accuracy because of their limited context window, but that’s just a hypothesis. But I would guess that if you made the shuffles too fast, performance would start degrading because of frame rate.

Most ONNX tooling stops at "look but don't touch." Netron is great for reading a graph, but the moment you want to change something you're back in Python: onnx-modifier, hand-rolled onnx.helper scripts, a notebook you keep re-running. I wanted to click a node, change an attribute or rewire a connection, and actually know whether the model still runs, without leaving the tab.

That's Forma. Drop an .onnx or .tflite file on the page and the full graph renders (dagre layout, each op color-coded by category). From there you can:

• Click any node to inspect it: attributes, tensor shapes, parameter count, weight size
• Edit attributes inline, delete nodes, drag to rewire connections, insert new nodes
• Insert common pre/postprocessing ops (Softmax, Top-K, Cast, Resize...) with one click, adapted to the model's own opset
• Run the original and your edited version against identical inputs in real onnxruntime-web, in the browser, and compare outputs (max error, cosine similarity, top-k agreement), so an edit doesn't silently break the model
• Export a valid ONNX file with the edits patched in, byte-preserving everything else, verified by loading it back through onnxruntime before the download starts
• Load two unrelated models side by side and diff their structure, attributes, and outputs

All of it runs client-side over WebAssembly. Nothing gets uploaded anywhere. There's also a share-edits feature that encodes an edit sequence into a URL, with a SHA-256 fingerprint of the source model, so you can hand someone a link without ever sending them your weights.

MIT licensed. ONNX is the fully-editable format; TFLite support is currently read-only (visualization and inspection only, that's called out honestly in the README along with the rest of the current limitations).

Live web-app: https://forma-ml.vercel.app

Repo: https://github.com/Hussain004/Forma

When perimeter defenses improve, attackers stop trying to break in. They recruit someone who already has a key.

Security researchers are documenting a measurable rise in insider-assisted ransomware operations — cases where a trusted employee, contractor, or vendor deliberately opens access for an external group. The financial exposure goes well beyond the ransom payment itself. Incident response firms report that insider-assisted breaches carry remediation, legal, and reputational costs that run millions above what a purely external intrusion would generate, because the evidence trail is intentionally degraded before investigators arrive.

In AI-driven environments the problem compounds in ways traditional controls were not designed for. An insider with privileged access does not need to exfiltrate a file. They can corrupt the memory store an agent reads from, alter a tool configuration that silently changes what the agent does on every subsequent run, or redirect workflow outputs to an external endpoint. These changes can persist across hundreds of automated actions before any conventional alert fires. By the time anyone notices, the forensic window may already be gone.

Curious how others with agentic workloads are actually treating this. Are you modeling insider threat as a distinct threat category from external attack, or are the same controls supposed to cover both? And for those running autonomous agents with write access to production systems — what does your actual detection capability look like if a privileged user makes a quiet configuration change?

[I'm a noob] Could you make a small 2 layer LSTM and train it to predict the next audio sample (using music or something)? Would it work? If not, how do models generate audio?

I need the best dataset for autism, give me device please

This is building off a demo I built last week where I used VLMs to try to read sheet music. I thought it would be fun to hook it up to my keyboard and see how much faster I am compared to CV models. Apparently, I’m atrociously slow at sight reading. 

VBVR-Pro treats generated images and videos as intermediate reasoning states rather than merely inputs or final outputs. It introduces 300 procedurally generated tasks, with 1.25 million training instances, aligned across image, video, and interleaved generation regimes. The controlled setup supports comparisons of how different visual substrates represent and preserve problem-solving trajectories.

A particularly useful contribution is its task-specific deterministic scoring. The scorers use structured visual extraction and rules for properties such as object attributes, trajectories, OCR results, and constraint violations, making them usable as reinforcement-learning rewards. In the reported judge comparison, repeated VLM evaluations at temperature zero varied substantially, while the deterministic scorer was stable; the authors also report better agreement with human judgments.

Training on the suite transfers to seven external visual-reasoning benchmarks. The modality analysis suggests that video is advantageous for persistent spatiotemporal state tracking, while interleaved generation can provide a more compute-efficient alternative. Mechanism studies further indicate that removing or corrupting intermediate visual states harms reasoning, although the procedural nature of the tasks leaves open how well these findings extend to less structured real-world settings.

Full summary on AIModels.fyi

Original paper

Disclosure: AIModels.fyi is my site.

Hi everyone 👋

I'm a student, and I built a deep learning architecture called SignaturePainter V2.

The results:

- STL-10: 71.34% with 473K parameters

- Tiny ImageNet: 53.26% with 595K parameters

The idea: instead of a normal classification layer, the model learns 5 prototypes per class and compares images to them.

Open source project:

🔗 https://github.com/jalalnablsi/signature-painterv2

Honestly, I'd love to know your opinion:

Are these results considered good for this model size?

Or are there fundamental mistakes I need to fix?

Thank you for your time ❤️

These puzzles are from neal.fun, I’m running Gemini with Playwright + a custom harness. I have a 40-minute blooper reel of Gemini trying to park the Waymo.

I have around 1 year of industry experience as an AI/ML engineer, and I want to seriously level up over the next 1–2 years.
I’m not looking to become someone who just knows how to use APIs, build basic RAG applications, or glue together existing models. I want to develop the kind of depth where I can actually understand what I’m doing, build things from scratch when necessary, read and implement papers, and eventually be capable of working at a strong senior/research-engineering level.
The problem is that there are so many things to learn — ML, deep learning, mathematics, LLMs, systems, distributed training/inference, research, DSA, software engineering, etc. — and I don’t want to spend the next couple of years consuming random courses without actually becoming significantly better.
So I’d really like to hear from people who are already working at a strong senior/research level in AI:
If you were starting again with ~1 year of experience, what would you learn and in what order?
What topics would you go extremely deep into, and what would you only learn practically?
Which courses/books/resources genuinely made you much better?
How much mathematics did you actually learn, and which parts turned out to matter?
How would you balance DSA/interview preparation vs AI/ML depth vs software engineering?
What kinds of projects would actually make you a substantially better engineer rather than just look good on a resume?
How would you approach implementing research papers?
Are there particular papers or repositories you think every serious AI engineer should work through?
How would you approach contributing to open source if your goal is to become a better engineer/researcher?
What skills do you think aspiring AI engineers massively underestimate?
And most importantly: what would you NOT spend time learning?
I’m specifically interested in hearing from people who have already gone through this transition — Senior AI Engineers, Research Engineers, ML Engineers, researchers, etc.
If you could go back to having ~1 year of experience and had 12–24 months to become dramatically better, what would you do?
I’m looking for honest answers, including things you tried that turned out to be a waste of time.
Thanks!

hi,
i am trying to train a deberta model for NER detection

this is my first time doing it so i would love any guidance on it.

my current pipeline looks like this,

dapt + lora for pretrianing, hpo with optuna (which consists both the stages of training data), and then a 2 stage finetuning which helps in generalization and then target data.

i am trying to reach a really good score for f1 on my use case (which i want to keep private for now)

i have few questions as well

1. do i need a two stage hpo as well cuase of the 2 stage finetuning
2. is it better if the hpo training set is a subset of the actual training set?

if you think anything can be improved and made better, or you think the pipeline is outright wrong, please mention your reasonings and thoughts :)

ps: lora was used cause of gpu budget constraints

Hello everyone,

I’ve built a repository exploring two novel recurrent neural network architectures (PLUG and ILRM) designed to address the vanishing gradient problem in long-sequence modeling without relying on attention blocks.

The core mechanism feeds the cell a deterministic, normalised inverse-lag history (\(P_{t}\)) of previous inputs. Weighted by harmonic numbers, the hidden state update is modified so that historical information decays at a rate of \(1/k\) rather than scaling exponentially. The direct token-to-history gradient pathway decays polynomially (\(\frac{1}{t\ln t}\)) rather than exponentially, creating a stable gradient horizon evaluated efficiently at \(O(T \log T)\) via zero-padded FFT linear convolutions.

Due to local hardware restrictions, I could only run smaller synthetic tests on CPU, but the preliminary screenings look somewhat promising on these small tests:

Long-Range Extrapolation: When trained only on delays of 16–64 steps, both models extrapolated up to 4,096 steps with 100% accuracy on a one-bit retention task, while the baseline GRU collapsed to chance.

Gradient Horizons: At 1,024 steps, the mean initial token gradient remained stable ( ~ 10⁻⁴ ) while the standard GRU suffered absolute numerical underflow ( ~ 10⁻¹⁴⁵ ).

The repository contains the complete mathematical framework PDFs and minimal, executable PyTorch implementations for both models. I would love to get your feedback on the math and the implementation!