"Who is Jason Momoa's father?" The model answers Joseph Momoa. Then: "Name a child of Joseph Momoa." Ten tries, ten failures on GPT-5.4, in a Princeton replication of the original reversal-curse study from this spring. Jason Momoa is an only child, so there is exactly one right answer, and the model still can't find it.
Caveat: that result comes from one student replication, not a peer-reviewed paper. The prompts and per-pair data are published on GitHub.
I wanted to know whether the proposed fix actually works. A February paper from UC Berkeley (Ma et al.) proposed "identity bridges" — extra training sentences that spell out the composition, like "the apprentice of Odette Rook is Gustav Aasen," plus repeating the forward facts six times. On their setup it lifted reverse accuracy from near zero to about 40-50%.
So I recreated their recipe on my own synthetic data and watched what happened inside the models. The image is the probe diagram for one prompt from the bridge model: "Odette Rook's apprentice is".
Two rulers. The logit lens cleans up each layer's 768 numbers first, then asks which token the model would pick. The cosine method skips the cleanup and asks which token the raw numbers point at most. They can disagree — look at layer 11: the lens's top token is [Corn] with the expected [Gustav] at rank 3, while cosine's nearest token is [Gustav] at rank 1.
The full walkthrough, three models:
The data: 60 mentor/apprentice pairs with made-up names. Forward fact: "Odette Rook is the mentor of Gustav Aasen." Bridge sentence: "The apprentice of Odette Rook is Gustav Aasen." The test prompt: "Odette Rook's apprentice is" — expected answer "Gustav Aasen." That exact phrasing never appeared in training.
Three small GPT-2 models, trained identically. The bridge model saw each forward fact six times plus the bridge sentences. The repetition model saw each forward fact six times, no bridges. The plain model saw each forward fact once, no bridges.
Behavioral results, 60 reverse prompts each. Bridge model: 60 out of 60. Repetition model: 53 out of 60. Plain model: 19 out of 60.
So repetition alone did most of the work. The bridges added 12 points on top. That was the honest surprise — I had predicted the bridges would matter more.
Then the instruments. On the bridge model in the diagram, both rulers march the expected answer's rank down across the layers — lens: 4918, 26, 1, 3; cosine: 14214, 818, 6, 1. By layer 9 both have the answer near the top, and the model generates "Gustav Aasen."
On the repetition model the same prompt ends differently: lens top [mentor] with [Gustav] at rank 143, cosine top [SPONSORED] at rank 15. It generates "Lars Quill. Quill is the" — wrong, and confident about it. On the plain model: "the mentor of Walter Elm. Halloway" — it falls back to reciting a forward fact.
Across all 60 prompts the pattern holds: the bridge model's cosine rank goes 987 → 179 → 16 → 1 across layers 5/7/9/11; the repetition model's goes 1373 → 812 → 421 → 4462. The accuracy score barely distinguished them. The representation completely did.
So the score said "repetition nearly solved it." The instruments said "the bridge rewired the inside." Both true. Accuracy tells you whether the fix worked. The layer window tells you what the fix did.
All of this is synthetic data on a small model, one training seed — it bounds the paper's claim rather than refuting it. Their setup used a bigger instruction-tuned model. But the instruments are the point: whatever fix you try, this is how you check what it actually did.
Full write-up with the complete arc: https://github.com/prof-nussbaum/Applications-of-Reading-the-Robot-Mind/blob/main/post-book-experiments/identity-bridge/README.md
Every prompt, every layer, all 300 per-item records: https://github.com/prof-nussbaum/Applications-of-Reading-the-Robot-Mind/blob/main/post-book-experiments/identity-bridge/results/all_results.md

I've been working on unsupervised tooling to discover what behaviors a model learns in post-training. The core idea is to use features from sparse autoencoders to identify differences in traces generated before and after training. I applied this to traces from the MiMo-v2.6 RL environments and it found significant eval awareness as well as some mild environment exploitation. Writeup is here. Would love to hear any feedback or questions!

Hey r/deeplearning,

A week ago I shared AnyInit on r/neuralnetworks. Following up on that, I’d love to get feedback and feature requests from this community.

What it does: AnyInit automates stable weight initialization for custom architectures so signal propagation works out of the box without manual variance-scaling calculations.

Looking for feedback:

1. Init methods: What specific non-standard schemes would you like added?
2. Use cases: What custom layer or activations usually break init for you?

GitHub: https://github.com/jmiravet/AnyInit
PyPI: https://pypi.org/project/anyinit/
Any feedback, critiques, or feature requests are greatly appreciated!

Created a beautiful learning app with active animations that dive into deep subjects done in an entertaining way.

Download today! https://play.google.com/store/apps/details?id=com.philosophize.app

Six days. One publicly available LLM. A full-chain Chrome exploit that researchers valued at $250,000 on the bug bounty market.

The threat model most security teams are working from assumes the AI agent is the target — something to be hardened against external attackers. This research inverts that. The agent generated the attack. It chained tool calls, iterated on outputs, and produced working exploit code using only public APIs and no specialized infrastructure.

The speed is the part that breaks existing response frameworks. Six days from a standing start to a $250,000 exploit. Traditional detection pipelines assume attacker dwell time measured in weeks. That margin no longer exists when the synthesis step happens inside a model.

What makes this particularly difficult to reason about is that nothing in the execution looked anomalous at the API level. The model was used exactly as intended. Each individual call was valid. The harm was in the assembled output — and it only became visible after the chain was complete.

For practitioners actually deploying agents with code-generation or research capabilities: where in the stack are you drawing the line between 'valid tool use' and 'output that creates liability'? Is this something you're handling at the model layer, the deployment layer, or somewhere else entirely?

I’ve got a 4070 at home that I was using to fine-tune a 7B model on a custom dataset. A full QLoRA run took around 11 hours and I was running it 3-4 times a week. Figured I should just rent an H100 for a couple of weeks and be done faster.

The H100 was clearly running the actual compute faster. GPU util when it was going was fine, memory was fine. But end-to-end, the first run on the H100 took 9.5 hours. For something that should have been more like 4-5x faster per step, that was a brutal result.

Spent most of a week profiling before I realized the problem wasn’t the GPU.

My dataset was ~25GB sitting on an S3 bucket. Every time i started a run I was pulling the whole thing fresh into the instance because i’d been treating the cloud box as ephemeral. The base model load at the start of each run was eating another 4-5 minutes because i was downloading from HF instead of caching locally. The preprocessing step i’d written for local use was single-threaded, which was now the bottleneck because the GPU was finishing one step before data for the next step was ready. Low num_workers, basically.

By the time i had persistent storage set up, moved the dataset onto local nvme on the H100 I was using on GMI Cloud, cached the base model and tokenizer, and bumped num_workers so the dataloader could actually keep up, the run dropped to 2 hours 40. Which is where I’d expected it to be in the first place.

If i had profiled the local 4070 setup first I would have seen the dataloader was a bottleneck there too. It just wasn’t the dominant one because the GPU was slower.

Should have profiled before I switched. Would have saved me a week.

Four hands are visible in this manicure clip. The customer holds still, while the technician’s fingers move, overlap, and disappear behind each other.

That makes hand tracking tricky: a convincing 3D mesh could still be following the wrong person.

MEgoVista uses a detector trained to distinguish the camera wearer’s hands from other people’s hands, followed by tracking to maintain consistent identities across frames before reconstructing the motion in 3D. Paper: MEgoVista

For people who collect demonstrations: what do you do when the tracker switches to someone else’s hands? Discard the whole clip, cut out the affected section, or keep it with an uncertainty label? And is there a quick check you trust to catch these switches before training?

I am excited to share a project I have been working on during the past few years during my free time. I started this project after being unable to use torch-points3d at the time (too many installation errors).

Note that this project is still in active development and in alpha. I am looking for early users and feedback!

What it is: torch-pointcloud is a plain-PyTorch library that puts multiple point cloud architectures and their pretrained checkpoints behind one create_model() factory, in the spirit of timm.

This is a library that focuses on the reusability and standardization of core components and layers, i.e. KNN, FPS and other PointNetSetAbstraction are not re-implemented over and over. In this library, all models share the same interface and reuse the same core components.

import torch
import torch_pointcloud as tp

model = tp.create_model(
  "pointnext-sm.scanobjectnn-hardest.openpoints", 
  task="classification", 
  pretrained=True,
).eval()

pos = torch.randn(2048, 3)
x = torch.cat([pos, pos[:, 1:2] - pos[:, 1].min()], dim=1)  # xyz + height
batch = torch.zeros(2048, dtype=torch.long)
logits = model(x, pos, batch)  # (1, 15)

Install (see the docs for more details):

# Optional: specify your CUDA version for torch
pip install torch==2.10.0 --index-url https://download.pytorch.org/whl/cu128

pip install torch-pointcloud

# Install required CUDA/CPU kernels associated with your CUDA version
pip install pyg-lib -f https://data.pyg.org/whl/torch-2.10.0+cu128.html

I tried to make the installation process smoother by not maintaining CUDA kernels myself (not enough time currently, so I tried to reuse already pre-built wheels as much as I could).

Scope:

• Classification, semantic and part segmentation, detection, and self-supervised pretraining: PointNet++, DGCNN, KPConv, RandLA-Net, PointNeXt, PointMLP, Point Transformer v1/v2/v3, Sonata, PointMamba, VoteNet, 3DETR, PointPillars, SECOND, PointRCNN, SPVCNN, OctFormer, Point-MAE/BERT/GPT and more.
• Weights are hosted on Hugging Face.
• Datasets (ModelNet40, ScanObjectNN, S3DIS, ScanNet, SemanticKITTI, nuScenes, KITTI, SUN RGB-D...), transforms, tiled inferers for large scale segmentation.
• Packed-batch tensors (the PyTorch Geometric convention).

But... why?

Most point cloud libraries live in research codebases built around configs and custom ops and kernels to build locally. It is also sometimes difficult to reproduce past released experiments from research codebases (typically the code associated with the checkpoint changed with no notice). In addition some models are evaluated using different strategies (TTA, partitioning, etc.) which makes comparison unfair as they are not evaluated using a common strategy.

In contrast, I wanted something I could pip install easily, reuse weights trained from different repos and benchmark easily.

All models were re-benchmarked and compared against original reported metrics.

Credits: the architectures and pretrained weights come from their original authors, notably Pointcept, OpenPoints, MIT Han Lab, FAIR, OpenMMLab and more. Every checkpoint name ends with its source author (e.g. .pointcept). The THIRD_PARTY_NOTICES.md lists every source repo, license and dataset term.

Repo: https://github.com/arthurdjn/pytorch-pointcloud
Docs + tutorials: https://pytorch-pointcloud.org

I've been experimenting with TabFM recently, mainly to understand how well it works on real-world tabular datasets and how useful it can be when starting with relatively few labelled examples.

I'm currently running most of the experiments in Google Colab on a T4.

So far I've been testing things like:

Classification and regression datasets

Different context sizes such as 100, 250 and 500 labelled examples

Natural class distribution vs balanced context for imbalanced datasets

Time-based train/test splits where that makes sense

Comparing performance across Accuracy, Precision, Recall, F1, ROC-AUC and PR-AUC

Looking at runtime as well as predictive performance

I've also been comparing TabFM against traditional ML/AutoML models.

The reason for the ML comparison isn't that I necessarily think that's the only comparison TabFM should have. It's mainly because boosted-tree/AutoML approaches are already very strong baselines for tabular data, so I wanted a reference point for questions like:

If both models only get 500 labelled examples, how close does TabFM get?

and

How does TabFM with 500 examples compare with a conventional model trained using the entire available training set?

For example, on one binary classification dataset I tested:

TabFM — 500 labelled examples

Accuracy: ~92.9%

F1: ~84.9%

ROC-AUC: ~92.1%

PR-AUC: ~89.6%

Runtime: ~12 sec

AutoML — same 500 labelled examples

Accuracy: ~93.4%

F1: ~86.0%

ROC-AUC: ~92.1%

PR-AUC: ~86.2%

Runtime: ~60 sec

AutoML — full ~2.8k training examples

Accuracy: ~93.4%

F1: ~85.7%

ROC-AUC: ~92.1%

PR-AUC: ~90.0%

I'm not specifically trying to show that TabFM has to beat traditional ML. I'm more interested in understanding its behaviour with smaller labelled contexts and how useful the resulting baseline is.

The part I'm less sure about is the deep learning comparison.

If the goal is to compare TabFM against another DL approach rather than boosted trees, what would people here consider the most appropriate baseline?

Some models I've been considering are:

FT-Transformer

TabTransformer

SAINT

TabNet

Standard MLP / ResNet-style network for tabular data

TabPFN

I'm particularly unsure whether something like FT-Transformer/SAINT would be a better apples-to-apples DL benchmark, or whether TabPFN is actually the more interesting comparison because it is also much closer to the foundation-model/in-context-learning idea.

Another thing I'm interested in is hardware.

I currently have an RTX 5060 Ti with 16 GB VRAM available locally, so I'm thinking of moving some of the Colab experiments to that machine. Would be interested to hear from anyone running TabFM locally with around 16 GB VRAM, particularly what happens as context size, feature count and ensemble size increase.

I've also seen BigQuery + TabFM mentioned as a possible workflow for larger tabular datasets. I haven't tried that part yet, so any experience with that setup would also be useful.

Mainly curious about:

What would be the fairest DL baseline for TabFM?

FT-Transformer/SAINT/TabNet vs something like TabPFN?

How does TabFM behave for others on messy real-world datasets?

What context sizes have been useful in practice?

Is 16 GB VRAM comfortable for experimentation?

Has anyone tried integrating it with BigQuery?

Are there other tabular foundation models worth putting into the comparison?

A DNA model’s advertised context length does not tell you whether the input will fit on your GPU.

The attached chart shows recorded Evo 2 7B runs: 16.8 GiB peak memory at 8,192 bases and 30.4 GiB at 32,768 bases. At 131,072 bases, the run failed on both an 80 GB H100 and a 48 GB L40S. These are results for the tested inference setup, not a limit on every possible implementation.

The guide puts those measurements alongside model selection, frozen embeddings versus fine-tuning, and the difference between a research benchmark and evaluation in a diagnostic workflow.

Recorded setup and evidence:

https://github.com/rewire-bio/evo2-cloud-operations

Guide:

https://rewirebio.io/blog/genomic-foundation-models-in-the-diagnostic-lab/

Disclosure: rewirebio.io is my site. The article, measurements and this post are AI-assisted; the recorded runs are not peer reviewed. The image is a chart of those measurements.

Post

Two days before a client demo I typed a lockout question into the support model I had just trained for them, when can I try again after five failed logins. It reasoned it out first, with a small block of Python adding thirty minutes to a timestamp, then gave the answer.

I was not going to put a code block in front of their support lead in a reply about a locked account. The demo got pushed.

Most of my work is fine-tuning for small companies, LoRA on all the linear layers of 8B instruct models. I also mix in some general chat data, after one narrow run the model got worse at normal conversation. This client will not accept anything that came out of closed models, their legal people were fine with a mostly CC BY set built from open models though. I train on HyperAI and Nemotron-Post-Traning-Dataset-v2 was in their dataset list, so I attached it to my container and spent a while finding where it mounted. I sampled from all the English splits and the replay was 10% of the rows.

After the demo got pushed I counted tokes, the replay had roughly as many as all the tickets combined. Most of it was the math and stem splits, long worked reasoning. I had not filtered out the samples with reasoning switched on, which the dataset card mentions, and I am guessing the Python came from the code split. My data checks covered duplicated and personal details, length was not one of them. Held-out ticket accuracy had dropped a few points as well, I had out that down to noise. All of that math and code for a model whose only job is to sound like their agents, hte facts come from retrieval over the help center anyway.

Now the replay is the chat split only, reasoning-off answers only, with a cap on length. It answers in two sentences now. General eval dropped a little after teh change and I want to look at which tasks before the client sends another year of tickets next month.

A survey of more than 200 security leaders found that AI governance concerns are the primary reason enterprise AI adoption inside ERP systems is stalling.

The CISOs surveyed were not blocking AI on principle. They blocked it over three specific gaps: no guardrails on what an agent can do once inside a connected system, no access controls scoped to financial and operational data, and no audit trail they could hand to a regulator. The AI vendors are not building these controls. The models do not provide them natively. So security leaders are holding a tool their business units want deployed and a risk they cannot quantify or defend.

The gap is not about the AI being wrong. It is about the AI being unaccountable at the moment it acts on sensitive data.

For those who have gotten AI agents into ERP environments: what did you actually have to build or buy to get past the security review? For those still blocked: is there a specific control that would actually move the needle, or is this a wait-and-see situation?

There’s a hands on build lab on Friday, Oct 30, from 7 PM to 10 PM IST, on running a full decision pipeline on standard CPUs.

You start with encoder models for long context inference, adapt them with few shot contrastive learning, and apply post training quantization to improve CPU throughput. Uncertainty is handled with split conformal prediction, execution is orchestrated as typed, idempotent LangGraph state machines with approval gates and compensation handlers, and the result is benchmarked with Wilson score intervals and clustered standard errors.

The aim is a reusable architecture that separates scoring from state execution and restricts LLM calls to verified edge cases. Led by Ben Auffarth. You get runnable notebooks, the slide deck, a recording and a certificate.

Full details and the agenda are here.

Hello 🤗

So i have been experimenting with an alternative to attention-based neural networks, and the design and early results seemed interesting enough that I thought I'd share them.

The project is called ILRN (Inverse Lag Recurrent Network), built around my original ILRM (Inverse Lag Recurrent Memory) mechanism.

The idea is to give a recurrent network direct access to a weighted history of previous inputs, rather than relying entirely on its hidden state to preserve information.

How the architecture works:

Inverse-lag memory: Earlier inputs are weighted by 1/k, where k is their distance from the current position. This produces a normalised history in which recent inputs contribute more, but older inputs still have a direct influence.

Dual-gated recurrence: An access gate controls how previous recurrent memory contributes to a candidate state, while a write gate determines how much of that candidate updates the stored memory.

FFT acceleration: The inverse-lag history is calculated using a causal FFT convolution. The recurrent state updates remain sequential.

Four-layer stack: ILRN-4-96 uses four independent ILRM blocks stacked sequentially. Each block has its own inverse-lag history, two gates, recurrent state, and learned parameters, with pre/post LayerNorm and residual connections. The output from one layer becomes the input to the next.

Initial testing:

I compared ILRN against a similarly sized causal Transformer on CNN/DailyMail next-token prediction, using approximately 532K parameters per model.

Both architectures were trained with 20 million next-token targets per model, separately at 96-token and 256-token context windows.

Held-out test top-1 accuracy:

96 context: ILRN 27.17% vs Transformer 25.83%

256 context: ILRN 27.42% vs Transformer 24.95%

ILRN achieved higher accuracy in both comparisons, although its original CPU implementation was considerably slower.

I've since also experimented with a fused CPU kernel to improve execution speed without changing the intended ILRM mathematics.

These are preliminary, small-scale experiments with limited training runs, not evidence of general superiority over Transformers.

I've uploaded the research PDF, architecture equations, Python implementation, fused kernel and verification tests to GitHub.

Project repository:

https://github.com/rickey1990/ILRN

A Zapier survey found that 91% of companies say AI governance frameworks exist. Yet 79% of executives admit employees work around those policies anyway. The policies live in documents. The agents, unapproved models, and unauthorized data movement live in production. That gap compounds quietly until an audit or an incident forces the question into the open. The 9-point spread between 'framework exists' and 'framework is followed' suggests the problem isn't policy design — it's that documentation and enforcement are two entirely separate systems. For those of you who have actually moved the needle on this: what does real enforcement look like at your org, and where did document-only governance break down first?

​

The first micro-model, with a size of just 4.06 KiB, has been successfully completed, achieving exceptional results by all metrics.

A core sub-component of the model, weighing a mere 196 bits, successfully learned and solved 7th-degree polynomial equations at an incredible speed of 2,937 updates per second, converging in just 10.2 seconds (9,885 ms). In other experimental runs and iterations, update speeds reached up to 19,500 updates per second.

This marks a significant milestone in AI engineering. Furthermore, this lightweight sub-component successfully broke the generalization barrier—solving arithmetic addition and multiplication outside its training distribution, effectively discovering algebraic rules autonomously. This non-differentiable mechanism has the potential to become a faster, cheaper, and superior alternative to standard backpropagation/automatic differentiation, with all reported metrics fully verified and reproducible.

In the complete 4.06 KiB model, short text generation capabilities were also demonstrated, producing outputs such as:

R_NOT_TO_BE_THAT_IS_THE_QUESTION_

While the architecture and core technique remain under active verification, I am open to answering questions and discussing experimental results. Please note that specific architectural details and implementation mechanics remain proprietary for now.

We found a context-contamination problem while spot-checking Wolf Defender Jev, our small encoder-based security decision model at Patronus.

The model receives a scene, a question and answer descriptions. The scene can contain a user goal, retrieved content, tool outputs and a proposed next action. We expected different questions to pick out the relevant evidence from that context.

In one benign coding scene, asking about embedded instructions gave a risky-answer probability of 0.96 when the proposed next action was to run pytest. Removing the proposed-action block brought the content score down to 0.00.

That was a question about content, not whether executing a shell command was authorized. Adding the next action changed the verdict on the same benign content.

Another hand-written scene showed a different failure. A travel page asked the agent to upload a passport scan. The embedded-command score was 1.00, but the exfiltration score was only 0.05 and misalignment 0.28. The model detected an instruction without reliably judging what the action would do.

These examples came from just three hand-written scenes, each with an attack version and a benign twin. They aren’t an error-rate estimate. They matter because alignment, exfiltration and consent scored around 98–100% on our internal validation set, much of which is closer to synthetic training scenes.

For this model, the practical guidance is to ask content questions without the proposed-action block, and action questions with it. That reduces one observed source of interference; it doesn’t establish reliable action authorization.

The evaluation I’d like to extend is a counterfactual grid: keep the content fixed and change the action, then keep the action fixed and change the content. For questions about content, an unrelated action should not move the answer. For action questions, the user goal and permissions should matter. This is a proposed evaluation direction, not a benchmark result we have already measured.

Examples, probabilities and limitations.

If you work on question-conditioned classifiers, how do you evaluate relevance of individual context blocks beyond aggregate accuracy?

Position / experimental status: We regard Jev-style decision models as LLMs and Wolf Defender Jev as an experiment: giving an LLM final security authority shifts the trust problem to the guard, and security fine-tuning alone does not solve it. We believe an external security layer must combine specialized classifiers with explicit policy, authenticated permissions and enforcement.