.png)
Sebastian Raschka published “Building an AI Text Detector From Scratch”, an end-to-end tutorial that covers dataset construction, model training, local deployment, and a verifier-style RLVR setup. The project is timely because Substack has just rolled out an AI text detector in its UI, and the post uses that as a concrete entry point rather than a generic detector overview.
The core idea is straightforward: build a small classifier that estimates whether a passage looks human-written or machine-generated, then use that score as a practical signal rather than a ground-truth verdict. Raschka frames it as both a detection demo and a verifier for training a small language model to produce text that avoids detection.
That framing matters. AI text detection is not a solved classification problem; it is a moving target shaped by model families, prompt styles, editing depth, and domain drift. A detector can still be useful as a spam filter, a writing assistant guardrail, or a research probe into how generator and detector dynamics interact. It is much less credible as an authoritative authorship oracle.
What makes this project interesting for ML engineers is the end-to-end scope. It is not just “fine-tune a classifier on synthetic vs human text.” It is a pipeline that includes how to assemble the training data, how to train a compact model, how to expose it locally, and how to reuse the detector as a learned verifier in an RLVR loop.
For this kind of system, the bottleneck is rarely the classifier architecture. The hard part is building a dataset that reflects the failure modes you care about.
A detector trained on clean, fully synthetic outputs versus untouched human text will usually look better on paper than it does in production. Real text often sits in the gray zone: human drafts polished by an LLM, generated text lightly edited by a human, copied boilerplate, SEO content, or a mix of source material and assistant rewrites. If the training set does not include those mixtures, the model will overfit to easy separations and fail where it matters.
That is where the Substack context is relevant. A platform-level detector is not only about flagging fully generated posts. It is also about content that has been revised by AI enough to look machine-like, even if the underlying ideas are human. The useful label is often not “AI” versus “human,” but “how much machine assistance is detectable under this distribution.”
For an engineer building such a dataset, the key design choice is coverage. You want examples spanning: - fully human drafts, - fully generated text, - lightly edited generations, - heavily edited human drafts, - domain-specific writing styles, - and multiple generator models and prompt regimes.
If the source content omits these axes, the detector becomes a style classifier for the training corpus rather than a robust AI-content detector.
Raschka explicitly positions the project as a local, do-it-yourself demo for small language models. That is the right scale for this problem space. A production detector does not need to be a giant model to be useful; it needs to be cheap, fast, and easy to inspect.
Local deployment also forces the right evaluation mindset. Once a detector is on-device or self-hosted, latency and calibration become first-class concerns. A raw probability score is not enough unless it is stable across lengths, domains, and writing styles. Short-form text, in particular, is notoriously brittle. Anything longer than a few hundred words gives the model more signal, but platform integrations often have to work on notes, comments, replies, or partial drafts where the signal is sparse.
The deeper issue is thresholding. A detector that is acceptable for triage may be useless if treated as a binary gate. Engineers should evaluate it with precision/recall tradeoffs, calibration curves, and slice-based analysis over domains and writing populations. If a detector is going to influence publishing, moderation, or editing workflows, false positives are the failure mode that will generate the most damage.
The most technically interesting part of the post is the RLVR angle: use the detector as a verifier to train a small model to write text that avoids detection. That turns the detector from a passive classifier into an optimization signal.
This is a useful pattern beyond text detection. Any learned scorer can become a verifier if its outputs are stable enough to guide generation. In practice, though, this also exposes the brittleness of the detector itself. If the model can be optimized against, then the detector is not measuring “authorship” so much as a set of detectable statistical quirks in a particular generator family or editing regime.
That does not make the setup useless. It makes it realistic. In adversarial settings, a detector should be expected to degrade under optimization pressure. If a small model can learn to evade it, that is evidence the verifier is capturing superficial cues rather than deep provenance. For research purposes, that is exactly the kind of failure you want to surface early.
I would treat this as a strong demonstration of the cat-and-mouse dynamic in AI detection. A detector can still add value, but only if the team is honest about what it measures and continuously refreshes data, generator coverage, and evaluation slices.
The practical lesson is less “build an AI detector” and more “build a scorer that is explicit about its uncertainty, robust to dataset shift, and useful as one component in a broader workflow.”
