Lesson 27 Dataset Preparation
Theme:

Theory

Reading time: ~20 minutes (~1500 words)  ·  Prerequisites: Lessons 24–26 (LoRA/QLoRA, API fine-tuning)

1. Why Dataset Quality Is the Bottleneck

When practitioners first approach fine-tuning, they tend to focus on model architecture, hyperparameters, and training infrastructure. These matter, but they are not where most fine-tuning projects fail. The single most common cause of a disappointing fine-tuned model is bad training data.

A fine-tuned model is, at its core, a compression of your dataset's patterns. If the data is noisy, inconsistent, or unrepresentative of your actual use case, the model will faithfully learn those problems. The LIMA paper (Zhou et al., 2023) demonstrated this dramatically: fine-tuning LLaMA-65B on just 1,000 carefully curated examples produced a model that competed with models trained on 50x more data. The key variable was not quantity — it was the care put into each individual example.

This principle holds across scales. Whether you are fine-tuning a 7B parameter open-source model with LoRA or using an API-based fine-tuning service, the quality of your dataset determines your ceiling. No amount of training epochs or learning rate tuning will fix fundamentally poor data.

2. The Instruction-Response Format

Supervised fine-tuning (SFT) teaches a model to follow instructions by showing it many examples of instruction-response pairs. The standard format includes three fields:

For chat-based fine-tuning (the format used by Anthropic and OpenAI), data is structured as a messages array with system, user, and assistant roles. Each conversation can contain multiple turns, which teaches the model to maintain context across a dialogue.

Regardless of format, consistency is critical. If some examples use Markdown headers and others use plain text, the model will produce a mix of both. If some responses are 50 words and others are 500, the model will have high variance in output length. Define your format conventions explicitly before creating any data, and enforce them throughout the pipeline.

3. Data Collection Strategies

Manual Creation

The gold standard. Domain experts write instruction-response pairs that reflect real use cases. This produces the highest-quality examples but is slow and expensive. The best approach is to start with a style guide: a document that defines the expected tone, format, length, terminology, and edge case handling. Give this guide to every annotator and include 5–10 reference examples.

Manual creation is most valuable for: seed datasets (the first 50–100 examples), edge cases that require domain expertise, and gold-standard evaluation sets.

Synthetic Data Generation

Use a strong model (e.g., Claude Sonnet 4) to generate training data for a weaker model. This is sometimes called distillation when the goal is to transfer capabilities from a larger model to a smaller one. The typical workflow is:

  1. Write 10–20 high-quality seed examples manually
  2. Prompt the strong model with those seeds as few-shot context plus a schema definition
  3. Generate hundreds or thousands of new examples
  4. Human-review a random sample (at least 10–20%) to catch systematic errors
  5. Filter out low-quality generations using automated quality scoring

Synthetic generation is powerful but comes with risks. The generating model's biases, errors, and stylistic quirks will propagate into your dataset. Always validate synthetic data — never use it blindly.

Document Conversion

Many organisations already have valuable knowledge locked in documentation, FAQs, support tickets, and internal wikis. Converting these into instruction-response pairs leverages existing assets without starting from scratch. Common conversion patterns include:

The challenge with document conversion is that source material was written for a different purpose. Answers in FAQs may reference other sections, use internal jargon without explanation, or assume context that will not be present at inference time. Every converted example needs review to ensure it stands alone.

4. The Cleaning Pipeline

Raw data — whether manually created, synthetically generated, or converted from documents — is never ready for training without cleaning. A robust cleaning pipeline has three core stages.

Deduplication

Duplicate examples cause the model to memorise specific patterns rather than learning general capabilities. There are two levels of deduplication:

Length Filtering

Set minimum and maximum token thresholds for both instructions and responses. Examples that are too short (e.g., one-word answers) are rarely informative. Examples that exceed your training context window will be truncated, potentially creating corrupted training signal. Typical thresholds:

FieldMin tokensMax tokens
Instruction5512
Output201024

These are starting points — adjust based on your task. A classification task might have shorter outputs; a summarisation task might need longer ones.

Quality Scoring

Use a strong model (the same one you used for generation, or a different one for independence) to score each example on a rubric. A simple rubric might score on three dimensions: correctness (is the answer right?), completeness (does it fully address the instruction?), and style (does it match the target voice?). Filter out examples below a threshold — typically 3 on a 1–5 scale.

For critical applications, complement automated scoring with human review. Even a small human-reviewed sample helps calibrate trust in the automated scores.

5. Train/Validation Splits

Splitting your dataset into training and validation sets is essential for detecting overfitting. The training set is what the model learns from; the validation set measures how well it generalises to unseen examples.

A typical split is 80–90% train, 10–20% validation. For small datasets (under 500 examples), use a higher validation proportion (20%) to get more reliable signal.

The critical rule: split before augmentation. If you generate 5 paraphrases of each question and then randomly split, versions of the same underlying question will appear in both train and validation. The model will appear to generalise well but will fail on truly novel inputs. This is data leakage, and it is one of the most common and most damaging mistakes in dataset preparation.

6. Data Augmentation

Augmentation increases your effective dataset size by creating variations of existing examples. Useful techniques include:

Remember: augmented variants of the same base example must stay in the same split. Tag each example with a group_id and split on groups, not individual examples.

7. Common Pitfalls Summary

PitfallSymptomPrevention
Data leakageHigh val accuracy, poor real-world performanceSplit before augmentation; check cross-split similarity
Bias amplificationModel excels on common topics, fails on rare onesAudit topic distribution; oversample underrepresented categories
Format overfittingEvery response starts the same wayVary response openings and structure across examples
Benchmark contaminationInflated eval scores that do not reflect real abilityScreen training data against standard benchmarks
Label noiseModel produces inconsistent or contradictory outputsUse quality scoring and human review; resolve contradictions

8. Tools of the Trade

Further Reading

Next lesson: Lesson 28 — Benchmarks & Evaluation, where we measure whether your fine-tuned model actually improved.