# Sparse autoencoders make a bad alarm and a great microscope.

A team wants a runtime monitor. The model is deployed, and the team needs to know — live, per request — when it is about to do a specific, known thing: enter a recognized failure mode, surface a sensitive topic, produce something the policy forbids. The team has been following interpretability research, and the answer looks like it has already arrived. Sparse autoencoders decompose a model's internal activations into a large dictionary of sparse, individually interpretable features. So the plan writes itself: find the SAE feature that corresponds to the bad concept, watch that feature on every forward pass, and raise an alarm when it fires. Interpretable, mechanistic, and — because the SAE was trained without labels — apparently free of the usual data-collection cost.

Sparse autoencoders are a genuine advance, and the enthusiasm behind the plan is not misplaced. It is just pointed at the wrong job. SAEs are very good at one thing, the team's monitor is a different thing, and the difference is not a detail.

"SAEs produce interpretable features" and "an SAE feature is a good monitor for a known concept" are different claims. The first is true. The second runs straight into a wall of benchmark results, and the gap between them is the subject of this post.

This post is about the two jobs people lump together as "using an SAE," why SAEs lose the comparison on the job the team picked, why they are additionally fragile as monitors, what they are genuinely the best tool for, and the one recent finding that complicates the picture.

## Two jobs that look like one

There are two activities people call "using an SAE to interpret a model," and they feel like one capability. They are not.

The first is **discovery**. You do not know what concepts a model has learned. You cannot even name them, so you have no labels and no hypothesis — you have a model and a question of the form "what is in here." An SAE's unsupervised decomposition answers exactly that: it produces a dictionary of features, and browsing that dictionary surfaces concepts you would never have thought to look for. The defining property of discovery is the absence of a target. You are not testing a hypothesis; you are generating one.

The second is **acting on a known concept**. Here you already have the concept in hand — "the model is being deceptive," "the model is about to refuse," "the input contains personal data" — and you want to detect it, steer it, or monitor it. The defining property of this job is that you _have_ a hypothesis, and a hypothesis you can name is a hypothesis you can label: collect examples where the concept is present and examples where it is absent. And the moment you have labels, the supervised baseline is on the table. You can train a linear probe — a logistic regression — on the labeled activations. You can take the difference of the mean activation between the two classes. These are cheap, old, and well understood.

That is the crux. For the discovery job, an SAE competes against nothing — there is no other tool that surfaces unnamed structure. For the known-concept job, an SAE competes against a logistic regression, and it has to win, because if it does not, the team should use the logistic regression. The team in the opening picked the second job — monitor a concept it can already name — and reached for the first job's tool.

## SAEs lose the supervised comparison

The reason this is a post and not a preference is that the comparison has been run, repeatedly, by interpretability researchers who wanted SAEs to win.

[_AxBench_](https://arxiv.org/abs/2501.17148) (arXiv 2501.17148) benchmarks SAEs against simple baselines on two known-concept tasks — concept detection and steering — on Gemma-2 models. On concept detection, measured by ROC AUC, the SAE scores roughly 0.63 to 0.76 across layers and model sizes, while difference-in-means scores 0.92 to 0.96 and a linear probe scores about 0.94. The SAE finished eighth of twelve methods. On steering, the SAE finished seventh of eleven, and the paper's summary does not hedge: "prompting outperforms all existing methods, followed by finetuning," and "on both evaluations, SAEs are not competitive." A gap of 0.2 in AUROC against difference-in-means is not a close contest — it is the SAE losing to the simplest supervised baseline there is.

[_Are Sparse Autoencoders Useful? A Case Study in Sparse Probing_](https://arxiv.org/abs/2502.16681) (arXiv 2502.16681) widens the test. It compares SAE probes against logistic regression across four hard regimes — data scarcity, class imbalance, label noise, and covariate shift — and finds the SAE probe underperforms logistic regression in every one of them on average. Across 113 datasets, the SAE probe beat the strongest baseline on 2.2% of them. Adding SAE probes to the toolkit of methods produced, in the paper's words, a slight _decrease_ in performance versus the baselines alone.

The mechanism behind the loss is worth stating, because it is not an artifact that better SAEs will fix. An SAE is trained to _reconstruct_ the model's activation, and a reconstruction necessarily encodes less information about a token than the original activation did — the framing paper below puts it as "a reconstruction encodes strictly less information about a token than the original LM representation." When you probe an SAE feature, you are probing a lossy copy of the thing a supervised probe gets to read directly. For detecting a concept you can name, the lossy copy is a handicap, not a help.

## SAEs barely beat a random baseline

The comparison against logistic regression is the headline. There is a quieter result that makes it worse.

[_Sanity Checks for Sparse Autoencoders_](https://arxiv.org/abs/2602.14111) (arXiv 2602.14111) asks whether trained SAEs beat _random_ baselines — random feature directions, no training at all. The margins are thin to absent: interpretability 0.90 for the trained SAE versus 0.87 for random, sparse probing 0.72 versus 0.69, and on causal editing the trained SAE does not pull clearly ahead. On synthetic data with known ground-truth features, the paper finds SAEs recover only about 9% of the true features even while explaining 71% of the variance — a model can look like it is capturing the structure and be missing most of it.

For the known-concept job, then, the SAE is not only losing to logistic regression. It is, on several of these tasks, barely distinguishing itself from a random projection. That is not a foundation to build a monitor on.

## SAEs break under a one-token nudge

Even if a team accepted a mediocre monitor, there is a property a monitor cannot lack: it has to be hard to fool. An SAE feature, used as a monitor, is easy to fool.

[_Evaluating Adversarial Robustness of Concept Representations in Sparse Autoencoders_](https://arxiv.org/abs/2505.16004) (arXiv 2505.16004) shows that a small adversarial perturbation — as little as a one-token suffix appended to the input — substantially shifts which SAE features fire, hijacking the concept reading. The damning part is the control: the same perturbation leaves the model's actual behavior essentially unchanged. A judge model found that for 0.98 of the one-token-suffix attacks there was no significant difference in the model's own self-summarization of what it did. So an attacker can move the SAE's concept readout — turn the "unsafe" feature off — without changing what the model is actually doing, and without changing what it is about to output.

A monitor whose reading can be flipped independently of the thing it is monitoring is not a safety control. It is an input surface the attacker also gets to write to. Wiring an SAE feature into a runtime alarm hands an adversary a switch labeled "silence the alarm" that does not touch the behavior the alarm exists to catch.

## What SAEs are actually for

None of this is an argument against sparse autoencoders. It is an argument about which job to give them.

[_Use Sparse Autoencoders to Discover Unknown Concepts, Not to Act on Known Concepts_](https://arxiv.org/abs/2506.23845) (arXiv 2506.23845) makes the case directly, and its central observation is that the discover-versus-act distinction "cleanly separates existing negative and positive results." The negative results — concept detection, steering, probing — are the known-concept job, and SAEs lose them, for the lossy-reconstruction reason above. The positive results are discovery: using an SAE's feature dictionary to generate hypotheses a researcher would not have posed, to surface concepts in a corpus, to find circuit structure. There, the SAE's unsupervised breadth is the whole value, because there is no supervised baseline to lose to — you cannot train a probe for a concept you have not yet named.

That is the microscope. A microscope is not an alarm. You do not point a microscope at a process and wait for it to buzz; you use it to look, offline, deliberately, at structure you did not know was there. SAEs are an excellent microscope. The team's mistake was reaching for a microscope when it needed a smoke detector.

## What the numbers do not say

Three honest qualifications, because the version of this argument that overstates loses the reader who knows the field.

First, the steering result is partly contested, and the contesting paper matters. [_SAEs Are Good for Steering — If You Select the Right Features_](https://arxiv.org/abs/2505.20063) (arXiv 2505.20063) argues that AxBench under-rates SAE steering because it selects steering features by their input activations and natural-language explanations — a criterion the paper finds has "little predictive power." Selecting features instead by their measured influence on the model's _output_ improves SAE steering by two to three times and makes it, in the paper's words, "competitive with supervised methods." Note the size of the claim: "competitive" is weaker than "SAEs win," but it is stronger than "SAEs lose," and it means part of the steering gap is a feature-selection methodology problem, not a fact about SAEs. The detection and probing results do not have a comparable rescue; the steering one does.

Second, the adversarial-fragility result is one-sided. It shows SAE concept readings can be flipped; it does not show that supervised probes are robust. Probes have their own adversarial weaknesses. The honest claim is "SAE features are demonstrably fragile as monitors," not "supervised probes are proven safe" — a monitor of any kind facing an adversary needs its own robustness evaluation.

Third, the discovery case is supported here mainly by the framing paper and the works it cites, rather than by discovery results re-verified independently in this analysis. "SAEs are a great microscope" is best read as "the negative and positive literature reconciles cleanly along the discover-versus-act axis" — a strong organizing claim, and the one the framing paper makes — not as a benchmarked head-to-head the way the negative results are.

## Using SAEs for the job they are good at

The choice is not SAE or no interpretability. It is matching the tool to the job.

**For a known concept, start with a supervised probe, and make anything fancier beat it.** If you can name the concept, you can label it; if you can label it, train a logistic regression or a difference-in-means probe. That is your baseline and, on the published evidence, often your answer. Any SAE-based alternative has to beat the probe on your data before it earns the deployment — the same discipline as [benchmarking a router against the trivial baseline](/blog/routers-lose-to-the-baseline/).

**Do not deploy an SAE feature as a runtime monitor without an adversarial evaluation.** SAE concept readings are flippable by small input perturbations that leave model behavior unchanged. If an SAE feature is going to gate anything, red-team it first: confirm an adversary cannot silence it without also changing the behavior it watches. A monitor that fails that test is not a monitor.

**Use SAEs offline, for discovery.** Point them at the job they win: surfacing concepts you did not know to look for, generating hypotheses, mapping circuits, auditing a model for the unknown. This is deliberate, offline, exploratory work — the microscope, not the alarm — and it is genuinely valuable, in the same family as the [interpretability tools you use to understand a system rather than to gate it](/blog/cot-is-not-an-audit-log/).

**If you steer with an SAE, select features by output influence, not input activation.** The contesting result is actionable: choosing steering features by their measured effect on the output, rather than by what they appear to activate on or how they are described, recovers most of the steering gap. If SAE steering is the path, use the selection criterion that works.

**Treat an SAE feature as a lead to verify, not a measurement to trust.** A feature that looks like "deception" is a hypothesis the SAE handed you. Confirm it against labeled data and against the model's actual behavior before any decision rests on it — and once you have that labeled data, notice that you now also have what you need to train the probe that will likely outperform it.

## The checklist

Before you rely on a sparse autoencoder for a concept you can already name:

- [ ] The task is identified as acting on a known concept (detect, probe, steer, monitor) rather than discovering an unknown one.
- [ ] A supervised baseline — logistic regression or difference-in-means — has been trained on labeled data and is the bar the SAE must clear.
- [ ] The SAE has been shown to beat that baseline on your own data, not assumed to because it is "interpretable."
- [ ] Any SAE feature used as a runtime monitor has passed an adversarial evaluation showing it cannot be flipped without changing the monitored behavior.
- [ ] SAE-based steering, if used, selects features by measured output influence, not by input activations or natural-language descriptions.
- [ ] SAE features informing a decision are verified against labeled data and observed behavior — treated as leads, not measurements.
- [ ] SAEs are scoped to offline discovery and auditing, where their unsupervised breadth has no supervised competitor to lose to.

## Reading list

- [_AxBench: Steering LLMs? Even Simple Baselines Outperform Sparse Autoencoders_](https://arxiv.org/abs/2501.17148) (arXiv 2501.17148) — on Gemma-2, SAEs score ~0.63–0.76 AUROC on concept detection against ~0.94–0.96 for a linear probe and difference-in-means, and finish 8th of 12 on detection and 7th of 11 on steering; "SAEs are not competitive."
- [_Are Sparse Autoencoders Useful? A Case Study in Sparse Probing_](https://arxiv.org/abs/2502.16681) (arXiv 2502.16681) — SAE probes underperform logistic regression in all four tested regimes and beat the strongest baseline on only 2.2% of 113 datasets.
- [_Evaluating Adversarial Robustness of Concept Representations in Sparse Autoencoders_](https://arxiv.org/abs/2505.16004) (arXiv 2505.16004) — a one-token adversarial suffix hijacks SAE concept readings while a judge finds no significant change in the model's behavior for 0.98 of attacks — SAE features are fragile as monitors.
- [_Use Sparse Autoencoders to Discover Unknown Concepts, Not to Act on Known Concepts_](https://arxiv.org/abs/2506.23845) (arXiv 2506.23845) — the framing paper: the discover-versus-act distinction cleanly separates the SAE literature's negative results from its positive ones, because a reconstruction encodes strictly less information than the original representation.
- [_Sanity Checks for Sparse Autoencoders: Do SAEs Beat Random Baselines?_](https://arxiv.org/abs/2602.14111) (arXiv 2602.14111) — trained SAEs barely separate from random baselines on probing and causal editing, and recover only ~9% of true features on synthetic data despite 71% explained variance.

The team wanted a smoke detector and the field handed it a microscope, and the two are easy to confuse because both are sold under the word "interpretability." But the team's monitor is a supervised detection problem — it has the concept, it can get the labels — and on supervised detection an SAE loses to a logistic regression and, worse, can be switched off by an adversary who never touches the behavior. Build the monitor from the probe. Keep the SAE for the work it is genuinely the best tool for: the offline, deliberate, hypothesis-free look at the model that turns up the concept nobody knew to write a probe for. The microscope is excellent. It was just never an alarm.