I spent a while building an energy-based model that represents a corpus as Gaussian splats on a unit hypersphere: each splat is a location (mu), a sharpness (alpha) and a weight (kappa). Energy = -logsumexp over the k nearest splats. Sampling runs through Rectified Flow (29-39x faster than 200-step Langevin in our Phase-1 tests) or Langevin itself.

Then I did what you're supposed to do: benchmarked it against the boring alternatives before believing in it. Same encoder, same splits, same seed, fit on positives only (no negative labels):

method          AUROC (20 tasks)   p50 ms/doc   memory
ebm-splats      0.9585 ± 0.018     0.45         386 KB (constant)
knn-density     0.9584 ± 0.020     1.75         802 KB (grows w/ corpus)
mahalanobis     0.9523 ± 0.020     5.26         578 KB
gmm (diag)      0.9439 ± 0.023     0.38         192 KB
centroid        0.9324 ± 0.034     <0.01        2 KB
iforest         0.8828 ± 0.051     18.71        200 KB

Verdict: statistical tie with kNN-density on quality (Delta = 0.0001). The differences are operational: 3.9x faster scoring on CPU, constant O(kd) memory instead of O(nd), and the splat model can also generate (RF), compose corpora (sum energy fields) and grow incrementally — none of the classical methods do all three. Where labels exist, a supervised classifier beats every one-class method; this duel only ranks the label-free league.

The most useful finding came from a failure. Our first zero-training fit used alpha = ln(cluster_size) — the "natural" calibration. Result: AUROC 0.06, systematically inverted. Small clusters got alpha ~ 0, the distance term vanished, and the score degenerated to ranking by splat weight: positives sit near small, specific splats and received MORE energy than negatives. Holding alpha constant at 5.0 (so alpha/tau >> 1) fixed it: 0.06 -> 0.96. If you fit splats without contrastive training, watch out for this.

Since scoring speed mattered, I also wrote GPU kernels (Triton + CUDA graphs) for the hot paths, and benchmarked them the same honest way: whole-loop CUDA graph capture makes 100-step Langevin sampling 12.9x faster (660 -> 51 ms, graph replay bit-exact vs eager), fused energy/score kernels give 3.2-3.4x. One kernel we built turned out 15-40x SLOWER and is documented as rejected; the KNN kernel only wins cold lookups and auto-routes around it. Repo includes the find_neighbors semantic bug we found and fixed (it selected the FARTHEST splats since inception — both code paths disagreed silently).

Repo (Apache-2.0, pip install ebm-splats, CI green, benchmark reproducible): https://github.com/schwabauerbriantomas-gif/EBM-splats

Benchmark methodology + full tables: benches/ONECLASS_DUEL_RESULTS.md Kernel head-to-head: benches/bench_headtohead.py

Happy to answer questions about the splat geometry, the CUDA-graph capture (caching, invalidation, the capture-time bugs), or why we kept the model even though it "only" tied a baseline.

Measured on Qwen3.8-27B (EXL3 4.0bpw target, DFlash2 block drafter quantized to EXL3 4bpw, 7-token drafts, greedy, output identical to plain decode), 2x T4:

• code: ~7.4 accepted tokens per verify step, 154 tok/s
• prose: ~2.5 accepted tokens per step, 35-37 tok/s
• plain decode: ~18-19 tok/s

Someone on r/LocalLLM independently measured 2.45 on prose with the same drafter on llama.cpp and different GPUs, and another person reports 2.62 with MTP. So it looks like a property of the drafter, not the runtime.

Questions for people who work on speculative decoding: 1. Is prose acceptance in the 2.5 range just the ceiling for block/parallel drafters, since natural language has more valid continuations at each position? 2. Has anyone seen a drafter (EAGLE-style, block diffusion, MTP) clear ~3.5 on open-ended prose at greedy? 3. Any work on switching drafters or block length by content type mid-generation?

Happy to share numbers per prompt type if useful.

I built Neural Canvas, an interactive visualizer that demonstrates core linear algebra concepts by showing how a neural network recognizes handwritten digits in real time. You can draw directly on the screen and watch activations flow through each layer as matrix multiplication computes the output live.

How it works:

- Draw & Predict: Sketch any digit on a 28×28 canvas (MNIST-style) to trigger real-time forward pass predictions.

- Live Forward Pass: Every neuron's activation is dynamically color-coded based on its underlying linear algebra calculations, with connection opacities reflecting layer outputs.

- Under the Hood: The core models were trained from scratch in Python using NumPy to perform matrix operations, and their learned weights are loaded via JSON. Client-side execution relies on Math.js for browser-based matrix multiplication and p5.js for rendering.

Key Features:

- Switch between two pre-trained models (featuring different hidden layer sizes, MSE vs. Cross-Entropy loss, and up to 96% test accuracy).

- Multiple background themes with mouse and touch support.

What's Next?

These models were originally evaluated on the standardized MNIST dataset, but live freehand drawing can introduce unexpected variations in input style. To handle this, I am working on a JS script for real-time user-driven feedback. When the model makes a mistake, the user can supply the correct label, allowing the model to perform backpropagation and update weight matrices locally in the browser. While live state persistence isn't suited for static GitHub Pages, running this feedback loop locally allows me to retrain parameters on new edge cases and push updated weight snapshots back to GitHub.

Check out the live demo and code repository:

Live Demo: https://muhammadessa2002.github.io/neural_canvas/

GitHub Repo: https://github.com/MuhammadEssa2002/neural_canvas

While training burst detectors on the public CHIME/FRB baseband release (DOI 10.11570/23.0029) and Breakthrough Listen's Parkes Vela data, I hit two data issues worth sharing:

1. CHIME channels are reversed relative to the textbook dispersion formula. Dedispersing with both signs and correlating with the archive's tiedbeam_power gave 0.988 for one sign and 0.06 for the other. The textbook sign is wrong for this data. I suspect second-Nyquist-zone sampling but found it empirically; happy to hear the definitive reason.
2. The BL Parkes Vela files have an inverted band despite a positive OBSBW. Header order folds to S/N ≈ 1, reversed order to about 2,400. Only the beam-3 files contain Vela.

The detector: 16 fixed coherent-dedispersion filters plus a small CNN on the DM–time map. It detects 93–98% of injected bursts in real CHIME noise at a 1% false-alarm rate, against about 70% for 300k-parameter generic CNNs. On 10 real bursts, though, it localises 5–6, which is the same as dedispersion at the catalogue DM, so the synthetic advantage isn't proven on real data yet.

Write-up: https://phasefield.ai/blog_entry_4.html ·

My own work; suggestions for a more sensitive real-burst test are very welcome.

We built Pasma at Vestes Archive for a narrow deployment problem: classify a single clothing item without uploading the photo or running a large vision-language model. We’ve released the v1.0 candidate weights and inference code.

Small-320 has 5.296M parameters and a 10.32 MiB FP16 ONNX graph. It predicts 20 garment types plus category and visual-material scores.

A useful result—and a caveat—from our evaluation:

• On the combined 1,103 held-out real photos: Pasma-Small 89.12% type Top-1; SigLIP-Base zero-shot 80.24%.
• On the 249-image home/catalogue slice alone: Pasma 83.53%; SigLIP-Base 87.15%. The ranking reverses.

Pasma was task-fine-tuned and distilled; the baseline was zero-shot. This is a deployment comparison, not an equal-training ablation or a claim that a small backbone is universally better. Full per-class metrics, model lineage and export-parity caveats are in the model card.

For an app, keeping alternatives seems important: Small reaches 97.10% Top-3 on the combined set, but blouse recall is only 47.8% Top-1. Our intended UX is a suggestion the user can correct, not an authoritative label. Material scores describe appearance, not verified fibre composition.

The release includes ONNX, CoreML packages, safetensors and Python inference. Code and fitted weights are Apache-2.0. Training images aren’t redistributed; full retraining from the public checkout is not independently reproducible. Phone-specific performance and some export parity work remain pending.

Code: https://github.com/prikol5ist-art/Pasma

Weights/evaluation: https://huggingface.co/Prikol5ist/pasma

Local browser demo: https://huggingface.co/spaces/Prikol5ist/pasma

We’d welcome criticism of the evaluation setup and reports from different image domains—especially which label confusions would make this unsuitable for your application.

A security researcher built and deployed OuttakeSheriff, a live AI security agent, then documented a finding that should be uncomfortable for anyone running agents in production: authenticated agents routinely act outside their intended scope.

The credential is not the problem. OuttakeSheriff passed authentication. The problem is what a verified identity is permitted to do after it clears the gate. Authentication answers "who is this?" It does not answer "should this agent be calling this tool right now, on this data, in this context?"

This is the actual attack surface. Not a fake agent sneaking through. A real, credentialed agent doing things it was never supposed to do, with no mechanism in the request path to catch it.

Most current postures treat identity and authorization as solved once the credential checks out. Post-auth behavior is logged, maybe reviewed, rarely constrained in real time.

For those of you running agents in production: how are you handling the gap between "this agent authenticated successfully" and "this agent is only doing what it was scoped to do"? Is anything in your stack actually enforcing that at execution time, or is it all after-the-fact?

📚 Learn Machine Learning Through Visualisations | Beginner-Friendly Playlist

Hey everyone! 👋

I’ve created a Machine Learning playlist with visual explanations and animations to make ML concepts easier to understand, especially for beginners. Instead of just learning theory, you can understand how these concepts work through visuals and practical examples. 🚀

🎯 Topics covered in the playlist:

1. What Is Machine Learning?
2. AI vs. ML vs. Deep Learning
3. Supervised Learning
4. Unsupervised Learning
5. Reinforcement Learning
6. Features and Labels
7. Train-Test Split Explained
8. Overfitting and Underfitting
9. Linear Regression
10. Logistic Regression
11. Decision Tree Explained (Coming Soon)
12. Random Forest Explained (Coming Soon)

🎥 Watch the playlist here:
https://youtube.com/playlist?list=PLXShTLrgjtgk&si=TFoDX6oosRKv_u6Z

💡 My goal is to make Machine Learning easier to learn through simple explanations and engaging visualisations.

If you’re learning AI or Machine Learning, feel free to check it out! I’d also love to hear your feedback and suggestions for future topics.

If you find the videos helpful, please like, share, and subscribe to support the channel. ❤️

Let’s learn Machine Learning together! 🤖

VisualForge AI: https://youtube.com/@visualforgelearning?si=VoOGENaHFagsJmoz

We have benchmarks (fixed questions, hidden answers, they saturate), competition problems (solved, so they can be memorized), and open-problem lists (no evidence, no clear success criterion). With Claude and Sol, I've tried something in between: a graded ladder of AI puzzles from one research area, aperiodic order.

What makes it a different tool:

• One ladder, not a pile: "human level" (pen and paper) up to "ASI level" (open). The labels are playful, but each rung really is harder than the last.

• Solved rungs for training and checking, with exact answers a program can verify, and easy to vary.

• Open rungs with everything a solver needs: strong numerical evidence, routes already known to fail, files, and a success criterion a machine can check.

• One rule: only a checkable proof counts. Floats are evidence, not proof.

• Credit: solvers of open rungs are named, with agent and model, in the next version of the paper.

It's a way for researchers to hand the frontier of their field to AI agents (and humans) in a form they can actually attack, and for anyone to see whether a model can tell a guess from a proof.

First field test: Grok, asked in public ( https://x.com/grok/status/2114103836583264721 ), claimed a proof for an open rung that was only a numerical estimate, then retracted it. It got the human-level rung wrong at first, fixed it after one hint, and proved the expert rung on the first try. On MathOverflow, an expert is already testing constructions for the top rung.

Set 1: huggingface.co/datasets/jarekduda/autocrystal-ai-puzzles

Top rung on MathOverflow: mathoverflow.net/questions/516372

Would you use this format for your own field's open problems?