LLM Text-Detector Failure: Why Model Turnover Breaks AI Screening in Science

LLM Text-Detector Failure: Why Model Turnover Breaks AI Screening in Science

Scientific journals have started using AI-written-text detectors to screen submissions—quickly deciding whether a manuscript looks “human” or “AI-assisted.” The problem is: the AI keeps changing. New large language model (LLM) versions arrive, and detectors that were tuned on yesterday’s models can start making weird mistakes. This new research—based on fresh work from Nakajima & Mizuno—shows that this isn’t a gradual problem. It can collapse suddenly at “model generation boundaries,” right when the LLM’s writing style shifts enough that detection logic no longer transfers.

What the authors quantify is the real-world weakness in current screening approaches: detector benchmarks are evaluated against a fixed set of LLM versions, but actual deployed screening faces a moving target. Their experiments simulate what happens when you keep the detector frozen, or update it in realistic ways, as 23 different LLM versions (from multiple vendors) roll out between June 2023 and August 2026. Spoiler: screening accuracy is not a stable property of a detector—it’s conditional on which LLM versions it last saw.

The takeaway is uncomfortable but important for research integrity. The paper argues that the benchmark performance of AI detectors should be treated as provisional and re-verified whenever LLM versions change—possibly even including “earlier” versions, not just the newest one.

Why This Matters (Right Now): Your Detector’s “Accuracy” Has an Expiration Date

Right now, a lot of people treat AI detectors like smoke alarms: if the threshold is set correctly, you assume the alarm is trustworthy. But this paper shows the detector’s “calibration” isn’t timeless—it’s tied to a specific set of LLM behaviors that drift across releases.

The timing is critical. Publishers and conferences want automation because reviewing every submission manually is expensive and slow. Meanwhile, LLM turnover is fast: in practice, authors can use the latest models the moment they’re available, while institutions update detectors less frequently (because retraining takes effort, vendor access may vary, and procurement/legal steps can slow everything down). That gap between “latest model in the wild” and “latest model in the detector” is exactly what Nakajima & Mizuno simulate—and it’s where performance can sharply fall.

A concrete scenario you could imagine happening today: a conference or journal uses a commercial detector with a fixed operating point (a fixed low false positive rate). The tool may catch most AI-written text from models it was effectively tuned for, but then a new LLM release hits the ecosystem. Suddenly, the detector can start missing a large fraction of rewrites for that new generation—while still flagging human-written text at very low rates. That means fewer appeals, fewer immediate red flags, and a higher chance that AI-assisted-but-not-disclosed rewrites slip through—especially around the first months after a new model version becomes widely used.

This also connects to earlier research on detector brittleness, but adds something crucial: it treats LLM turnover as a structured, time-ordered process with measurable “jumps” between model generations. Previous work often demonstrated that detectors struggle when tested on LLMs they weren’t trained on. This paper goes further by showing where failures concentrate, how vocabulary shifts predict those failures, and how different deployment strategies split the errors between false positives (flagging humans) and false negatives (missing AI rewrites). You can’t fix that just by publishing one benchmark score once.

What the Researchers Actually Measured: Turnover-Aware Detection Across 23 LLM Versions

The authors build a large, controlled dataset and then train/evaluate detectors under maintenance scenarios that mirror real deployment.

The dataset: human abstracts + LLM rewrites across many versions

They start with 34,925 English abstracts from PNAS (Proceedings of the National Academy of Sciences), published 2009–2018. The assumption is that this window precedes the mass adoption of ChatGPT-style AI rewriting.

From those, they randomly sample 4,000 abstracts (equal across four domains). Then they rewrite each of the 4,000 abstracts using 23 LLM versions from three vendors (OpenAI, Meta, Alibaba). That creates 91,953 retained rewrites after filtering issues like truncation/empty outputs.

They focus on a specific use case: AI-rewritten text, meaning an LLM rewrites existing human-written abstracts (not just generating text from scratch).

The detectors: controlled thresholds and “low false positives”

The core evaluation setup is a familiar one in detection research: set a threshold so the detector flags only a small fraction of human-written texts.

• They calibrate each detector to flag 1% of human-written abstracts as AI-rewritten (false positive rate = 1%).
• The main reported metric is true positive rate (TPR) at 1% FPR: among AI-rewritten abstracts, how many are caught above that threshold?

The key experimental twist: detectors updated (or not) as LLMs change

They consider four “maintenance scenarios” for each LLM version being screened v:

Then they also test combined screening strategies—more on that soon.

Baseline observation: public detectors that weren’t trained for this corpus mostly miss everything

Before training their own detectors, they test four publicly released, non-commercial detectors (including OpenAI’s GPT-2 output detector, RADAR, Fast-DetectGPT, and Binoculars). Without any in-domain training on their rewritten abstract corpus, these detectors miss more than two-thirds of rewrites of every version.

That sets the stage: if a detector isn’t trained/maintained for the domain and the rewriting style, its benchmark numbers may look “okay” at a broad level—but it won’t actually catch much in practice.

Where Detection Breaks: Sharp Collapses at Model Generation Boundaries

Here’s the most striking part of the paper. Detection doesn’t just get slightly worse over time. It can collapse at specific transitions.

Near-perfect detection when the detector is trained on the exact version

When they train a detector with access to the current version it screens, performance is almost perfect:

• Median TPR across all 23 versions is 99.9% (when trained on that version).
• Under past and current versions, the median is 99.3%.

So if the institution keeps up with model releases extremely well, detectors can work—at least in this controlled setting.

Big drops when the detector trains only on earlier versions

The “past versions only” scenario is what most resembles real-world deployment timing: the new LLM version arrives before the detector has new training data.

In this case:
- Out of the versions where earlier versions exist, detection stays above 85% for most cases (median TPR 95.4%).
- But there are two major collapses:
- GPT-5 first version of its generation: TPR drops to 26.6%
- Muse-Glimmer first open-weight model of Meta’s Muse family: TPR drops to 3.8%

So detectors can remain reliable for many updates—and then fail catastrophically when the generation boundary hits.

“Frozen detectors” can become nearly useless

They also test detectors never updated after training on an early version. Those results show how brittle things can get:

• A detector frozen at GPT-4 catches at most 0.6% of rewrites from GPT-5 onward.
• A detector frozen at Qwen2.5 still catches 86% of rewrites of Qwen3.8—so it’s not uniformly doomed, but it’s highly dependent on which transition happens.

Why those collapses? Vocabulary shift is a major predictor

The authors dig into what causes detection transfer to work for some transitions and fail for others. Their leading hypothesis is vocabulary difference.

They compute a measure of vocabulary distribution distance using Jensen–Shannon divergence (JSD) between rewrite corpora of different versions. Then they compare JSD to detection transfer performance.

Result: larger vocabulary shift strongly corresponds to worse cross-version detection.

• Across 253 unordered pairs of versions, the correlation between JSD and average TPR is ρ = −0.85 (p < 0.001).

In plain terms: when the LLM’s rewritten abstracts start using substantially different word patterns, a detector trained on the earlier generation doesn’t generalize well.

And two extreme failures line up with the biggest vocabulary jumps from their nearest predecessor from the same vendor:
- Muse-Glimmer (to GPT-5-like boundary behavior) is among the worst.
- GPT-5 is among the worst.

Training and Screening Strategies: You Can Trade False Positives for False Negatives (and Vice Versa)

Once you accept that detection breaks across model boundaries, the next practical question is: how should an institution screen submissions without causing unfair harm or letting AI text slip through?

The paper simulates two screening designs at scale, assuming you have access to training data/rewrite corpora for all 23 versions.

Strategy A: “Union” of version-specific detectors (high recall, higher false flags)

In the union scenario:
- You train one detector per LLM version.
- Each detector is calibrated to its own 1% FPR.
- You flag an abstract if any detector fires.

Because false flags accumulate across detectors, humans get hit.

Their key result:
- The union flags about 11.9% ± 1.2% of held-out human-written abstracts.
- That’s roughly one in eight humans falsely flagged.

But the payoff is high recall for AI rewrites:
- The union catches nearly all AI-rewritten abstracts.
- Even for Muse-Glimmer, the union catches 98.6% of rewrites on average.

Strategy B: One pooled “generalist” detector (low false flags, misses some new generations)

In the pooled scenario:
- You train a single detector on pooled rewrites from all 23 versions.
- You calibrate it to flag 1% human-written text.

What happens?
- It stays near the intended false positive rate: 0.8% ± 0.3% of human-written abstracts flagged.
- But it misses some AI rewrites, especially for the hardest transitions.

The miss rates are version-dependent:
- Median miss rate across versions: 2.8%
- Worst case:
- Muse-Glimmer: 33.8% ± 3.4% missed
- Next: Qwen2.5 (8.8%) and GPT-5.6 Terra (6.6%)

So the institution protects humans from unnecessary flagging—but risks letting a meaningful fraction of AI rewrites through, particularly from the most boundary-shifted generation.

What changes when versions arrive over time (not all at once)?

In real deployments, you don’t instantly get data for all future versions. The authors simulate progressive rollout by adding detectors version-by-version in release date order.

They focus on errors for the newest hardest model generation (Muse-Glimmer, treated as the last released among their 23).

• In union, human false flags climb as more detectors are added, reaching 11.9% at k=23.
• In pooled, human false flags remain near 1% throughout—but misses remain huge until Muse-Glimmer is included in training.

In short: union protects against missing AI but punishes humans; pooled protects humans but can miss new-model rewrites until the training set “catches up.”

Commercial Reality Check: A Deployed Detector Mostly Flags Humans Rarely—But Misses Many New Rewrites

The paper also evaluates a real deployed commercial detector: Pangram.

They send:
- 400 AI-rewritten abstracts per LLM version
- 5,000 calibration human-written abstracts
- Using the vendor’s default production model: 3.3.2

The detector outputs three labels:
- fully AI-generated
- AI-assisted, but not fully AI-generated
- fully human-written

For evaluation, they treat a rewrite as “missed” only when Pangram labels it fully human-written, i.e., the most favorable-to-the-detector condition.

What they find is consistent with the pooled scenario’s “low false flags, higher misses” tendency:

• False positive rate on human-written calibration: 0.02% (1 of 5,000)
• Miss rate on AI rewrites varies drastically by LLM version:
  • as low as 6.5% for GPT-5
  • up to 79.8% for Muse-Glimmer

They also observe uneven misses across domains (e.g., higher misses in Health Sciences than Social Sciences), which mirrors prior findings that detection error can be unequal across communities.

The practical implication: if you rely on a single fixed operating point and never re-check after major LLM updates, your detector can silently shift from “helpful” to “mostly blind” for particular new generations—while still looking great on low false positive metrics.

Key Takeaways

Key Takeaways

• Detector accuracy is not stable. It depends heavily on which LLM versions you trained on and when the newest models arrived. (This is the paper’s main warning, quantified.)
• Failures can be sudden. In the “past versions only” scenario, detection can collapse at model generation boundaries—e.g., GPT-5 first version (TPR 26.6%) and Muse-Glimmer first open-weight release (TPR 3.8%).
• Vocabulary shift predicts detection transfer. The paper finds a strong relationship between rewrite-vocabulary distance (JSD) and how well detection carries over across versions (ρ = −0.85).
• Union vs pooled screening creates a trade-off:
  • Union (many specialized detectors): catches most AI rewrites but flags humans heavily (~11.9% false flags, about 1 in 8).
  • Pooled (one general detector): keeps false flags low (~0.8%) but misses many rewrites for boundary-shifted versions (e.g., Muse-Glimmer miss rate 33.8%).
• Commercial tools can look “good” while missing the newest models. Pangram’s human false positive rate was extremely low (0.02%), yet it missed up to 79.8% of rewrites for Muse-Glimmer.
• Policy implication: treat benchmark scores as provisional. The paper argues detectors need re-verification with every LLM release—and possibly even testing coverage of earlier versions, not just the newest one.

If you’re involved in research integrity, the headline is pretty simple: AI screening can’t be a one-and-done benchmark. LLM turnover means detection performance has an operational half-life unless the system is actively maintained and re-validated as models evolve.