DetectorScope: Google DeepMind Releases an AI Text Detector That Shows Its Work

Most AI-text detectors give you a number and nothing else. DetectorScope, a new repository from google-deepmind on GitHub, gives you the number plus the reasons: "the word about used as a preposition" nudged the score up by 0.23, "conversational filler phrase like i said" nudged it down by 0.05. The project accompanies the paper Building Auditable AI Text Detectors with Sparse Autoencoders by Liam Dugan, Callum McDougall, Matthew Denton, Philip Pham, Christine Kaeser-Chen and Chris Callison-Burch, accepted at EMNLP 2026 in Budapest.

The short version: the authors take a fine-tuned neural detector, train sparse autoencoders (SAEs) on its internals, keep only the features that can be described in plain language and checked against the text, and train a small linear model on top. The result stays close to the black-box detector it came from, but every verdict can be read and challenged. If you have followed the SAE additivity research or the interpretability push at labs, this is one of the first places that machinery is aimed at a tool that affects ordinary people.

TL;DR: DetectorScope in questions

Why AI text detectors have a trust problem

Detectors are now used in consequential places. The paper's abstract lists peer review, education, admissions, journalism and content moderation, "where their outputs directly affect individuals." The strongest detectors are fine-tuned neural classifiers whose decisions nobody can inspect. Transparent alternatives, such as stylometric or linguistic-feature classifiers, are readable but, in the authors' words, "underperform them by wide margins."

That gap has produced real disputes. We covered a Goncourt-prize controversy where a detector's verdict was contested, a Gmail labeler false positive, and an earlier look at classical machine-learning detection with SVMs. In each case the missing piece is the same: the person accused cannot see why. DetectorScope's pitch is that you should not have to choose between accuracy and an explanation.

How DetectorScope works

The README describes the detector as a concept bottleneck over interpretable sparse-autoencoder features. In four steps:

1. Fine-tune a classifier. Gemma-2-2b is fine-tuned to separate human from AI text.
2. Train SAEs on its residual stream. An SAE breaks the model's internal activations into many sparse features. If the idea is new to you, our guide to Anthropic's natural language autoencoders covers the neighboring approach, and the Goodfire write-up on clean neurons shows how the field argues about interpretability.
3. Describe and validate every feature. Each feature gets a natural-language description (the pipeline's autointerpret stage calls Gemini) and a score for how well that description predicts where the feature fires. A threshold on that score decides which features survive.
4. Fit a sparse head. A logistic-regression head (or an XGBoost head) is trained only on the surviving features.

Because the head is linear, the arithmetic is exact. The README says importance is "how much the logit falls if the feature is silenced," and that logit == bias + sum(importances). Nothing is hidden in a final opaque layer.

What the output looks like

The README's example input is "Like I said, this is about accuracy, about speed, and about cost." The detector returns a label of ai with p_ai=0.88, then features such as "the word about used as a preposition" (+0.23), "repeated phrases or sequences in text" (+0.14) and "conversational filler phrase like i said" (-0.05). Setting return_highlights=True also returns the tokens and, for each feature, the token indexes and activation strengths, which is what the demo uses to highlight the text when you hover.

Notice what this does for a reader. A phrase like "repeated phrases" is a hypothesis you can test by eye. If a detector flags your own paragraph because of a feature that does not actually appear there, you have grounds to doubt it.

The tau dial: interpretability versus accuracy

A tuning fork shifting a bead between rails, like the tau threshold in an auditable AI text detector trading legibility for accuracy

The most practical idea in the package is tau. Each feature has an auto-interpretation score, and tau is the score a feature must reach before the head may use it. The README spells out the trade:

• A higher tau (up to 0.95) gives the head fewer, better-described features, so every item of evidence "is one you can read and check, at some cost in accuracy."
• A lower tau (down to 0.00, every feature) admits looser descriptions, and "the detector gets more accurate and less legible."
• The default is 0.85, and tau moves in steps of 0.05.

Every released branch carries a head at every step, so changing tau downloads nothing. You can even compare one text at several settings in a single script:

from detectorscope import AuditableDetector

detector = AuditableDetector.from_pretrained("liamdugan/detector-scope")
text = "Like I said, this is about accuracy, about speed, and about cost."

for tau in (0.50, 0.85, 0.95):
    out = detector(text, tau=tau)
    print(tau, out.label, round(out.p_ai, 2), len(out.features))

The pattern to watch is how many features carry the verdict as tau rises. If the label flips between 0.50 and 0.95, the evidence was resting on features nobody could describe well, which is exactly the case where you should not trust the result.

Does the interpretable version give up accuracy?

According to the README, the answer is "minimal adverse effects on performance." The authors evaluate with F1 on the COLING 2025 GenAI detection benchmark and true-positive rate at 5% false-positive rate on RAID, in domain and out of domain, and report that the auditable detectors "stay close to the fine-tuned black-box classifier they are built on." One figure caption adds that the fine-tuned-model-plus-SAE variant "matches the underlying neural detector even at thresholds of 0.7 and above." The paper's abstract goes further and says the extracted-feature classifiers "exhibit stronger performance on out-of-distribution texts than either neural or stylometric alternatives."

We have not rerun the benchmarks, and the exact tables are in the paper, so treat these as the authors' claims. Out-of-distribution robustness is the number to scrutinize: it is the setting where real-world detectors tend to fail.

The released models

Three detector collections are on Hugging Face, each with three settings stored as branches:

The branches are ft-model-sae (fine-tune Gemma-2-2b and the SAEs), ft-sae (unmodified Gemma-2-2b, fine-tuned SAEs) and base-sae (both unmodified, using stock Gemma Scope SAEs). main points to whichever performed best: ft-sae for the open domain and ft-model-sae for peer reviews. Load a branch with revision="base-sae". The README notes that every branch bundles its language model, so nothing else is downloaded.

Beyond detection: reading what LLMs sound like

The README lists a second use: "Analyze LLM outputs so that you understand which models have which tendencies." Because the features are named, you can ask which ones fire most for one generator versus another. That turns a detector into a style microscope, a cousin of the stylistic habits readers already notice in chatbot prose. It also means the repo can help writers: seeing which of your phrasings trigger "AI-like" features is a more actionable edit list than a bare percentage.

The experiment scripts in the repo point the same direction. They include a counterfactual ablation (zero-ablation versus a targeted paraphrase of a single feature), a feature-guided paraphrase attack and a check of how well feature descriptions can be matched by regular expressions. The paraphrase attack deserves attention: if you can see which features drive a detector, you can also rewrite text to avoid them. The authors published it deliberately, which is a reasonable choice, but it means this is not a tool that will hold up against someone who wants to evade it.

Reproducing it yourself

The pipeline runs as python -m detectorscope.<stage>: finetune, train_sae, data.extract and data.process, autointerpret (set GEMINI_API_KEY), the head training modules and evaluate. The README says stages 0 to 2 need a GPU and the rest runs on CPUs. A Gradio app lives in demo/ and runs locally with python demo/app.py. The paper's tables and figures are regenerated from scripts/visualization/analysis.ipynb.

Because the pipeline is generic, the authors present it as a way to "convert your own black-box detector into an auditable one." If your team already runs a detector, the cost is training SAEs on its residual stream and validating features with an LLM judge. That is not trivial, but it is far cheaper than training a detector from scratch.

What the authors say you must not do

The disclaimer is unusually blunt, and worth quoting in full spirit. The detectors "are research artifacts released to support the paper. They make mistakes, including on text written by people, and their accuracy outside the domains and generators they were trained on is not established. They must not be used as the basis for decisions about individuals, such as academic integrity, hiring or publication decisions."

Three points follow:

• An explanation is not proof. A readable reason can still be wrong. A feature description that sounds right may still fire on human writing, which is why the tau threshold exists.
• Domain shift is real. The peer-review detectors were trained on one kind of text and one pair of generators. Applying them to student essays or news is outside what was tested.
• Funding context. The README acknowledges support from DARPA's SciFy program and IARPA's BENGAL program, with the usual note that views are the authors' own. That is background, not a claim about deployment.

For anyone building a process around detection, the safer reading is: use DetectorScope to understand and debug detectors, not to accuse people. Our posts on lawyers sanctioned for AI-invented citations and on the flood of AI papers hitting arXiv show why institutions want detection, and why wrongly accusing someone is the costly failure.

What this means for builders

If you ship a detector or a moderation classifier, DetectorScope is a template for adding evidence to your outputs: SAEs, validated feature descriptions, a sparse head and a tunable threshold. If you evaluate other people's detectors, it is a way to ask what the model is actually keying on. If you are just curious, the hosted demo takes seconds. Either way, expect scrutiny of the claim that interpretability costs nothing; it is a paper result on two benchmarks, and the repo had zero stars and ten commits when we read it.

Related reading

• SAE additivity residuals: do sparse autoencoder features add up?
• Goncourt, Pangram and an AI detector's contested verdict
• Pangram's Gmail AI labeler and a false positive
• LLM-generated text detection with classical ML
• Anthropic natural language autoencoders
• Goodfire on interpretable neurons
• Official: repository, paper on arXiv, ACL Anthology entry, Hugging Face demo

Details reflect the repository README and arXiv listing as of October 24, 2026; the repo is new and may change.