Fine-Tuning
Intermediate 12 min read Fine-Tuning

When to Tune

Evidence before weights

The decision to fine-tune should rest on evidence: prompted quality has plateaued AND a dataset exists AND the problem sits in a tunable layer. Jumping to tuning for symptoms prompting fixes is a common waste.

when to tunedecisionbaselineplateaucosttradeoff
Prerequisites: Fine-Tuning Overview
Before we start

What you will learn

  • Gate tuning on a measured baseline
  • Enumerate signs tuning is warranted
  • Model the cost of tuning
Introduction

What is this?

Tune when three things hold: the prompt/few-shot baseline has measurably plateaued, you have (or can build) a representative dataset, and the improvement gap is worth the training cost + ongoing eval discipline. If prompted few-shot closes the gap, that decision is cheaper and reversible.

Motivation

Why do you need it?

  • Tuning spends real money and adds maintenance surface.
  • Baselines measure whether it's actually worth it.
  • Prompt-level fixes are reversible; weight-level aren't.
  • Dataset availability often decides feasibility — before strategy.
Think about it

Mental model

Imagine

Buying a machine vs. hiring more staff

Think of

Tuning decision

You buy the machine (tune) when labor (prompts/few-shot) is at capacity and volume justifies the capital. Not because machines are 'advanced'. If weekend staff close the gap cheaper, you hire first. Tuning is the machine: justified by throughput math, not fashion.

Mechanics

How it works

  • Establish the prompted/few-shot baseline eval on held-out data.
  • Identify the residual gap (formats, style, correctness).
  • Assess data availability and augmentation options.
  • Cost out tuning + serving + eval maintenance.
  • Decide: tune now, later, or improve prompting instead.

Decision gate.

Baseline
Gap?
Data?
Cost
Tune
Real world

In production

  • Support teams tune only after few-shot hits broadplateau.
  • Format-critical extraction tunes when formats drift despite prompts.
  • Tool-intent models tune once schema churn stabilizes.
Guidelines

Best practices

  • Write the baseline down before tuning — decisions need numbers.
  • Tune for behaviors, not facts (facts go to retrieval).
  • Re-evaluate 'still worth tuning' at every model upgrade.
  • Use the smallest model that clears the bar.
Watch out

Common mistakes

  • Tuning for problems prompting could have fixed (waste).
  • No baseline — 'I feel it's better'.
  • Tuning knowledge into weights instead of using RAG.
Root cause analysis

Common issues

Error
Team tuned and saw no gain
Root cause

No baseline discipline

Fix

Retro: build baseline, compare, stop if flat.

Error
Tuned model breaks on new domain
Root cause

Dataset too narrow

Fix

Augment with diverse coverage; eval out-of-domain.

When things break

Debugging tips

  • Tune candidate underperforms baseline → data fidelity; inspect.
  • Improvements evaporate on new models → re-run the gate on upgrade.
  • Costs balloon at scale → smaller model or fewer epochs.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

Before tuning, establish a…

2

Facts and knowledge belong in fine-tuned weights.

Go deeper

Official documentation

When to fine-tune (OpenAI)
docs