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:
- Instruction: What the model should do (the task description or user query)
- Input: Optional context or data the model should work with
- Output: The ideal response the model should produce
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:
- Write 10–20 high-quality seed examples manually
- Prompt the strong model with those seeds as few-shot context plus a schema definition
- Generate hundreds or thousands of new examples
- Human-review a random sample (at least 10–20%) to catch systematic errors
- 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:
- FAQ to Q&A: Each question becomes an instruction; each answer becomes the output
- Documentation to how-to: Section headings become "How do I...?" instructions; section content becomes the response
- Support tickets to dialogue: Customer messages become user turns; agent responses become assistant turns
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:
- Exact dedup: Hash each example (instruction + output concatenated) and remove identical hashes. Fast and essential.
- Near-dedup: Use techniques like MinHash with Locality-Sensitive Hashing (LSH) to find examples that are nearly identical — e.g., the same question with slightly different wording. The
datasketchlibrary makes this straightforward in Python.
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:
| Field | Min tokens | Max tokens |
|---|---|---|
| Instruction | 5 | 512 |
| Output | 20 | 1024 |
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:
- Instruction paraphrasing: Rewrite the same question 3–5 different ways to teach the model to handle varied phrasing
- Input noise injection: Add realistic typos, informal language, or formatting inconsistencies to inputs so the model handles messy real-world text
- Output style variation: For the same instruction, provide both concise and detailed responses (labelled appropriately)
- Negative examples: Include examples of incorrect or inappropriate responses marked with explanations of why they are wrong
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
| Pitfall | Symptom | Prevention |
|---|---|---|
| Data leakage | High val accuracy, poor real-world performance | Split before augmentation; check cross-split similarity |
| Bias amplification | Model excels on common topics, fails on rare ones | Audit topic distribution; oversample underrepresented categories |
| Format overfitting | Every response starts the same way | Vary response openings and structure across examples |
| Benchmark contamination | Inflated eval scores that do not reflect real ability | Screen training data against standard benchmarks |
| Label noise | Model produces inconsistent or contradictory outputs | Use quality scoring and human review; resolve contradictions |
8. Tools of the Trade
datasets(Hugging Face): Loading, filtering, mapping, and saving datasets in standard formats. Handles JSONL, CSV, Parquet, and streaming for large datasets.pandas: Data manipulation, deduplication, statistical analysis of your dataset.datasketch: MinHash and LSH for near-duplicate detection at scale.tiktoken: Token counting for length filtering (proxy for most tokenisers).scikit-learn:train_test_splitwith group-aware splitting viaGroupShuffleSplit.
Further Reading
- LIMA: Less Is More for Alignment — Zhou et al. (2023). The landmark paper on quality over quantity for fine-tuning.
- Textbooks Are All You Need — Gunasekar et al. (2023). Microsoft's phi-1 paper demonstrating that high-quality synthetic data can train remarkably capable small models.
- Self-Instruct — Wang et al. (2023). Framework for using a model to generate its own instruction-following training data.
- Hugging Face Datasets Documentation — Official docs for the
datasetslibrary.
Next lesson: Lesson 28 — Benchmarks & Evaluation, where we measure whether your fine-tuned model actually improved.