Fine-tuning can teach a model a consistent format, tone or specialized task — but the result is only as good as the examples you train on. Most failed fine-tuning projects fail at the data stage, not the training stage. This guide walks through building a dataset that actually improves the model.

1. Decide whether you need fine-tuning

Try prompting with good instructions and examples, and retrieval for knowledge, first. Fine-tune when you need consistent behaviour that prompts cannot reliably produce: a strict output format, a house style, a narrow classification task at scale, or a smaller, cheaper model that matches a larger one on your task. See build, buy or fine-tune.

2. Define the target behaviour precisely

Write a short specification: input types, the ideal output, tone, length, what to do with ambiguous or out-of-scope inputs, and examples of good and bad outputs. This becomes your labelling guide and your evaluation criteria.

3. Collect examples

Sources include:

  • Historical data: past support replies, reports or classifications — after checking quality and permissions.
  • Expert-written examples: slower but highest quality.
  • Synthetic examples: generated by a stronger model and reviewed by people, useful to cover rare cases.

Quality beats quantity. The LIMA paper (2023) showed that a model fine-tuned on about 1,000 carefully curated examples could produce strong responses, suggesting that well-chosen examples matter more than sheer volume for style and format. For narrow tasks, hundreds to a few thousand good examples are a common starting point.

4. Cover the real distribution

Include easy, typical and hard cases; edge cases and refusals; different lengths, languages and formats your users produce. A dataset of only clean, easy examples produces a model that breaks on real input.

5. Clean and check

  • Remove duplicates and near-duplicates.
  • Fix or drop examples with wrong labels or poor outputs.
  • Remove personal data and secrets, or get the right legal basis to use them.
  • Make outputs consistent with your specification — inconsistent examples teach inconsistent behaviour.
  • Check licensing and permission for every source.

6. Format

Use the chat or instruction format your training tool expects (usually JSON lines with system, user and assistant messages). Keep the system prompt the same as you will use in production, and include only the information the model will actually have at inference time.

7. Split the data

Hold out a test set (10–20%) that is never used in training, and ideally a separate validation set for tuning hyperparameters. Make sure near-duplicates do not appear in both training and test sets, or results will be inflated.

8. Evaluate before and after

Run the base model on your test set first to get a baseline. After training — for example with parameter-efficient methods like LoRA — compare on the same set, check format adherence, and read samples. Also test general behaviour to make sure the model did not get worse at things you still need.

9. Iterate

Analyse failures, add or fix examples where the model is weak, and retrain. Keep the dataset versioned so you know which data produced which model.

Example training record

A typical chat-format record for a support-reply task looks like this:

{"messages": [
  {"role": "system", "content": "You are the support assistant for Acme. Reply in under 120 words, friendly and precise."},
  {"role": "user", "content": "My order #1234 arrived damaged. What can I do?"},
  {"role": "assistant", "content": "Sorry about that! You can request a free replacement or a refund within 30 days..."}
]}

Every record should follow the same structure and the same system prompt you will use in production.

Document the dataset

Keep a short datasheet next to every dataset version: where the examples came from, how they were labelled and reviewed, what was removed, known gaps and the licence of each source. It makes results reproducible, helps anyone who retrains the model later, and answers the questions customers and regulators increasingly ask about training data.

What to watch next

  • Synthetic data pipelines with human review.
  • Preference-based fine-tuning becoming as easy as supervised tuning.
  • Tools that detect label errors and duplicates automatically.
  • Licensing rules for using customer data in training.

Key takeaways

  • Try prompting and retrieval before fine-tuning.
  • Write a precise specification of the target behaviour first.
  • A few hundred to a few thousand high-quality examples often beat large noisy sets.
  • Clean, deduplicate, remove personal data and check permissions.
  • Hold out a test set and compare against a baseline before and after training.

Frequently asked questions

How many examples do I need?

For narrow tasks, hundreds to a few thousand good examples are a common start. Quality and coverage matter more than volume.

Can I use synthetic data?

Yes, especially for rare cases, but have people review it and mix it with real examples.

Does fine-tuning add new knowledge?

It is better at teaching behaviour and format than facts; use retrieval for knowledge that changes.