When a fine-tuned model underperforms, the instinct is to blame the base model, the learning rate, or the prompt template. These are rarely the cause. In the vast majority of cases, the problem is in the data — and it was there before training started.
The challenge is that dataset problems are invisible at training time. Loss curves can look healthy while the dataset is quietly teaching the model to be inconsistent, overconfident, or memorize sensitive information. You only see the damage at evaluation time — or worse, in production.
Here are the seven mistakes we encounter most frequently, and what to do about each.
Mistake 01 Near-Duplicate Contamination
What it looks like: Your dataset contains many examples that are semantically identical or near-identical — the same contract clause with minor wording differences, the same FAQ answer reformatted, the same news story from multiple sources.
Why it's harmful: Near-duplicates cause the model to overweight those patterns during training. The effect is subtle: the model becomes disproportionately confident on inputs that resemble the duplicated content, and underperforms on genuinely novel inputs. Duplicate-heavy fine-tuning also accelerates overfitting, manifesting as strong benchmark scores on your eval set (which contains similar duplicates) but poor generalization in production.
Exact deduplication alone is insufficient. In a typical enterprise corpus, near-duplicate content (Jaccard similarity >0.80) that escapes exact matching accounts for 10–25% of records.
Run MinHash LSH deduplication with a Jaccard threshold between 0.80–0.85 after exact hash deduplication. Use 5-gram shingles and 128 permutations for a good precision/recall tradeoff. The text-dedup library handles this at scale. Expect to remove an additional 10–25% of records beyond exact deduplication.
Mistake 02 Train/Eval Contamination
What it looks like: Examples from your evaluation set, or content highly similar to your eval examples, appear in your training set.
Why it's harmful: This is the most deceptive dataset problem because it makes your model look better than it is. Eval scores are inflated because the model has effectively seen the answers during training. When you deploy, real-world performance is significantly worse than your eval metrics suggested. This is called "benchmark contamination" at scale, but it happens just as commonly in custom fine-tuning projects.
Run MinHash similarity checks between your training and evaluation splits before training — not after. Any training example with Jaccard similarity above 0.70 to an eval example should be removed from training. If you're using a public benchmark as your eval set, cross-check your training data against the benchmark's known examples.
Mistake 03 Unredacted PII in Training Data
What it looks like: Real names, email addresses, phone numbers, SSNs, or other personally identifiable information appear in your training examples.
Why it's harmful: LLMs are capable of memorizing training data, particularly information that appears repeatedly or in high-attention positions (beginnings of documents, structured fields). A model trained on data containing customer PII can reproduce that PII at inference time in response to crafted prompts — a direct regulatory violation under GDPR Article 5, HIPAA, and CCPA. Beyond the legal risk, PII in training data is also a security vulnerability: the trained model weights themselves become a data breach risk.
LLM memorization of training data has been demonstrated empirically by researchers who extracted verbatim training examples from GPT-2 and other models via targeted prompting. This is not theoretical.
Run automated PII detection using a combination of regex patterns (for structured identifiers like SSNs, phone numbers, credit cards) and a transformer-based NER model (for names, locations, organizations). Microsoft Presidio is purpose-built for this. Replace detected entities with consistent synthetic tokens like [PERSON] rather than blank redactions — synthetic tokens preserve grammatical structure and dataset utility. See our data cleaning pipeline guide for implementation details.
Mistake 04 Inconsistent Instruction Format
What it looks like: Your JSONL dataset mixes multiple prompt formats — some examples use Alpaca format, others use ChatML, others use raw text completion format — sometimes even within the same file.
Why it's harmful: Format inconsistency teaches the model to be format-inconsistent. At inference time, the model will produce outputs in unpredictable formats depending on which training examples "activated" most strongly. This is especially damaging for structured output tasks (JSON generation, table filling, code completion) where format correctness is a hard requirement. It also inflates training loss in a misleading way — the model is wasting capacity learning multiple schemas simultaneously.
Choose one format (ChatML is the most portable across modern frameworks) and convert every example to it before training. Validate format consistency programmatically: parse every JSONL record, confirm the required keys exist and have the correct types, and assert that role values are only "system", "user", or "assistant". Reject any record that fails validation rather than silently passing it.
Mistake 05 Token Length Distribution Mismatch
What it looks like: Most of your training examples are short (under 100 tokens) but your production use case involves long inputs (500–2000 tokens), or vice versa.
Why it's harmful: Fine-tuning on short examples teaches the model to respond in short patterns — it will truncate or summarize long-context inputs rather than reasoning through them. Conversely, fine-tuning exclusively on very long examples wastes compute on padding tokens and degrades performance on short inputs. The token length distribution of your training data shapes the model's output behavior more directly than most practitioners expect.
Tokenize your entire dataset with your target model's actual tokenizer and plot the length distribution before training. The distribution should roughly match your expected production input lengths. If it doesn't, either collect more examples in the underrepresented length range, or apply length-stratified sampling to rebalance the distribution before training.
Mistake 06 Low-Quality Responses in Instruction Pairs
What it looks like: Your instruction/response pairs include responses that are vague, incorrect, off-topic, or stylistically inconsistent with your target output quality.
Why it's harmful: The model learns from both good and bad examples equally. Low-quality responses in your training set directly lower the ceiling of your fine-tuned model's output quality. This is especially common when instruction pairs are generated automatically (by a larger model or by scraping QA pairs from the web) without a quality review pass.
Score each response on a multi-axis rubric: relevance to the instruction, factual accuracy (if verifiable), response length appropriateness, and format compliance. For high-stakes use cases, route low-scoring responses to human review before including them in the training set. If you used a model to generate responses, use a stronger model or a human reviewer to score them — do not assume generated responses are uniformly high quality.
Mistake 07 Missing Negative Examples for Safety-Critical Tasks
What it looks like: For tasks like content moderation, refusal behavior, or structured extraction, your training set contains only positive examples of the desired behavior with no examples of what the model should refuse or how it should handle ambiguous edge cases.
Why it's harmful: A model trained only on positive examples of a safety-critical behavior has no signal for when to decline or express uncertainty. It learns to confidently produce outputs for every input, including the ones it should reject. For moderation tasks, this means missed detections. For extraction tasks, this means hallucinated fields instead of empty responses for inputs that don't contain the target information.
Deliberately include negative examples: inputs that should produce a refusal, an empty extraction result, or an "I don't know" response. A rough guideline is that 15–25% of your training examples should represent edge cases or rejection scenarios. For RLHF-trained models, ensure your preference pairs include examples where the "rejected" response represents the exact failure mode you're trying to prevent.
The common thread: All seven of these mistakes are detectable before training starts — with the right validation pipeline. Fixing them after training means retraining from scratch. Build dataset validation into your pipeline, not your post-mortem.
If you'd like an expert assessment of your training data before you commit to a fine-tuning run, request a free data audit. We assess your dataset for all seven of these issues and deliver a prioritized remediation report within 48 hours.
Get Your Dataset Audited Before Training
We check for all seven of these issues — and more — inside your infrastructure. Free audit, 48-hour turnaround.
Request Free Data Audit →