Fine-tuning data

The training job is the easy part. Data quality is the job. Every label error becomes policy. A few hundred consistent, production-shaped examples often beat tens of thousands of noisy ones.

What "good data" means

• Match production inputs. Same metadata, same messiness, same languages, same tool-call traces if you tune for tool use.
• Gold outputs from your best system. Often a frontier model plus the best prompt plus a human edit. Do not distill mediocrity.
• Held-out evals before you train. Freeze a suite that includes the prompted baseline. Ship the fine-tune only if it wins on quality, or on cost and latency at matched quality.
• Synthetic data from a teacher is useful, then spot-check. Diversity matters. Near-duplicates waste capacity and inflate fake metrics.
• Watch general regressions. Narrow SFT can hurt unrelated skills. Include a small general-capability smoke set if the model still does open chat.

How much data?

Rules of thumb, not laws.

• Classification-style tasks often move with hundreds of clean labels.
• Generative style transfer may need low thousands of diverse exemplars.
• Distillation for a broad assistant skill wants more coverage still.

Always plot eval score vs dataset size on a pilot. If 500 examples score about the same as 2,000, stop collecting junk and fix the label guidelines.

Split explicitly: train, validation (for early stopping and hyperparameters), and a held-out product eval that never influences training decisions except go or no-go. Contaminating the product suite with training paraphrases is how teams "beat" the baseline in the lab and flop in production.

Preference data

For DPO-style runs, collect pairs where the difference is the behavior you care about. Prefer pairs from real failures: a bad production reply vs the edited good reply. Noisy preferences teach mush.

Walking through an invoice extractor

You want an 8B open model to match GPT-class extraction on invoices.

• Teacher produces 2,000 JSON outputs, validated by schema and checksum rules.
• 200 held-out invoices never appear in training.
• Prompted 8B baseline: 71% exact schema-and-field match.
• After LoRA SFT: 89%, and p50 latency drops from 1.8 s on a large API to 0.4 s self-hosted.

Cost and quality both win, so you keep it. If SFT had hit 73% with ugly edge-case regressions, you would delete the adapter and fix the schema prompt instead.

held-out invoices     = 200
baseline match        = 71%
after LoRA SFT        = 89%
latency p50           = 1.8 s  →  0.4 s

The 200 held-out invoices are the only number you trust. The 2,000 training rows are not an eval.

Common mistakes

• Quantity over consistency. Ten thousand noisy labels write ten thousand errors into the weights.
• Training on the product suite. The score goes up in the lab and nowhere else.
• Preference pairs with no real difference. "A is slightly nicer" does not teach the behavior you need.

Check yourself

1. You have 500 clean labels and 2,000 noisy ones. The pilot scores match. What do you do? Stop collecting. Fix the label guidelines. The extra 1,500 are not helping.
2. Why freeze the product eval before you train? So the go or no-go number is not contaminated by examples the trainer already saw.

Key takeaways

• A few hundred consistent examples beat a pile of noisy ones.
• Match production inputs. Gold comes from your best system, then a human edit.
• Split train, validation and a held-out product eval.
• Plot score vs dataset size. If the curve is flat, fix labels, not volume.

Further learning

Next, decide how you will host and refresh the model in serving fine-tunes. Measure every candidate on the same eval suite.