Continuous Fine-Tuning Without Data Contamination: The Production Pipeline

Most teams running continuous fine-tuning discover the contamination problem the same way: their eval metrics keep improving each week, the team celebrates, and then a user reports that the model has "gotten worse." When you investigate, you realize your evaluation benchmark has been quietly leaking into your training data for months. Every metric that looked like capability gain was memorization.

The numbers are worse than intuition suggests. LLaMA 2 had over 16% of MMLU examples contaminated — with 11% severely contaminated (more than 80% token overlap). GPT-2 scored 15 percentage points higher on contaminated benchmarks versus clean ones. These are not edge cases. In a continuous fine-tuning loop, contamination is the default outcome unless you architect explicitly against it.

This post covers the production engineering required to run ongoing fine-tuning from user feedback without compromising your evaluation signal, causing your model to forget earlier capabilities, or degrading safety properties that no one is manually reviewing.

Why Continuous Fine-Tuning Is Different from One-Shot Training

In a one-shot training run, contamination prevention is relatively straightforward: hold out a test set before training begins, never touch it during training, evaluate once at the end. The temporal boundary is clean.

Continuous fine-tuning breaks this model in three ways.

First, your evaluation benchmarks are static but your training data is a live stream. As user interactions accumulate, the probability that some training example resembles an eval example increases monotonically. If you're pulling from a large enough user base over a long enough time period, you will eventually see near-duplicates of your held-out examples.

Second, the feedback loop creates self-reinforcing errors. If the model answers a question in a particular style and users approve that answer, that interaction becomes training signal. But if the model was wrong in a systematic way — say, hallucinating a specific statistic that users failed to catch — you're now training on confident wrong answers. The eval metrics won't catch this unless you designed your evaluation to specifically test that failure mode.

Third, safety alignment erodes between iterations. Fine-tuning on just 10 adversarially designed examples is enough to jailbreak GPT-3.5 Turbo's safety guardrails. Even 50–100 entirely benign examples can degrade alignment in categories like Malware and Economic Harm. When you're running fine-tuning continuously without manual review between each iteration, safety regression is a silent accumulating risk.

The Data Routing Architecture

The foundation of contamination prevention is strict physical separation between data that flows into training and data that flows into evaluation. These two pipelines must never share state.

The architecture looks like this: all user interactions first pass through a classification gateway. The gateway's job is to route each interaction to one of two places — the training pipeline or the evaluation traffic bucket. Evaluation traffic is sampled for quality review and used to update your held-out metrics; it never touches the fine-tuning dataset.

Within the training pipeline, every incoming example passes through a contamination check before being written to the training store. This check uses hash-based near-duplicate detection against a registry of your evaluation examples. If an incoming training example is too similar to any eval example — measured by Jaccard similarity over 5-grams — it gets dropped.

The evaluation benchmark itself lives in a separate, append-only store with access controls. The rule is simple: nothing in the fine-tuning loop can read from it. The benchmark updates periodically, but only through a controlled process that explicitly checks new benchmark additions against existing training data before accepting them.

One implementation detail matters a lot: the gateway that routes user traffic must operate on a separate code path from the fine-tuning job. If the same service reads from the routing gateway and writes to the training store, you've created a path for contamination through shared state. Use a feature store abstraction with strict read/write separation.

Contamination Detection at Scale

Hash-based deduplication using MinHash and locality-sensitive hashing (LSH) is the practical tool for detecting near-duplicates at scale. The approach converts each document to a set of character n-grams, applies N hash functions to create a signature, then uses LSH bucketing to find candidates with high Jaccard similarity.

The practical performance is good enough for production: 100,000 documents can be deduplicated in under four minutes on commodity hardware. At trillion-token scale, GPU-accelerated variants using parallel rolling polynomial hashing handle the job in hours. For most continuous fine-tuning workloads, the simpler CPU-based approach runs fast enough to be part of the real-time ingestion pipeline rather than a batch job.

The key parameter to tune is your similarity threshold. A threshold that's too low creates false positives — you drop legitimate training examples because they superficially resemble eval examples. A threshold that's too high misses paraphrased contamination. For most applications, 5-gram similarity above 0.8 Jaccard similarity is a reasonable starting point.

Beyond hash-based detection, there's a class of methods that look at model internals. The most robust of these (DICE — detecting in-distribution contamination) identifies the most sensitive layer in the model for a given piece of data by measuring Euclidean distance between hidden states on contaminated versus uncontaminated examples. A small classifier trained on those internal representations achieves 99.5–99.9 AUROC on realistic contamination scenarios, with R² of 0.61–0.75 between predicted contamination and actual benchmark inflation. The limitation is that you need known contaminated examples to train the classifier — it's better suited for post-hoc auditing than real-time filtering.

Preventing Catastrophic Forgetting

The opposite failure mode from contamination is catastrophic forgetting: the model improves at the target task and simultaneously gets worse at everything else. This is especially common when the fine-tuning data distribution is narrow relative to the model's original training distribution.

The most reliable mitigation is replay buffers. The idea is straightforward: maintain a store of examples from previous training rounds and mix them into each new fine-tuning batch. The tricky part is which examples to keep when your buffer has limited capacity.

Loading…