Fine-Tuning

Quick Answer

Fine-tuning continues a pre-trained model's training on your own examples, adjusting its weights so it adopts a behaviour: a format, a tone, a task pattern, a domain's conventions. It shapes how the model responds, and it is a poor way to inject facts. Facts belong in retrieval; behaviour belongs in fine-tuning.

What is Fine-Tuning?

Fine-tuning takes a model that already knows language and shows it hundreds or thousands of examples of the exact behaviour you want, input paired with ideal output, nudging its weights until that behaviour becomes its default.

The result is a model that produces your format, your tone, or your task pattern without being told every time.

The distinction that saves teams the most money: fine-tuning changes behaviour, retrieval changes knowledge. A model tuned on your support transcripts learns to sound like your support team. It does not reliably learn your current refund policy, and it certainly does not track the policy when it changes next month.

Worth stating plainly, because the vocabulary gets abused: companies fine-tune or prompt existing models. Training a model from scratch is a different undertaking at a different order of cost, and describing tuning as "training our own AI" misstates both.

Why Fine-Tuning Matters Now

last reviewed: July 2026

Two developments moved tuning from research luxury to routine engineering option.

The first is parameter-efficient tuning, led by LoRA (low-rank adaptation), which freezes the base model and trains a small set of added weights instead. A tuning run that once needed a cluster fits on modest GPUs, and the output is a small adapter file rather than a full model copy.

The second is the small-model economy. The strongest production case for tuning is making a small, cheap model perform like a large one on a single narrow task.

At volume, that swap is one of the few AI decisions with a directly measurable payback, provided evals confirm the small model holds the bar.

How Fine-Tuning Works

1. A dataset of demonstrations: Hundreds to thousands of input-output pairs showing the target behaviour. The dataset is the product. Quality and coverage here decide the outcome more than any training setting.
2. Supervised training (SFT): The model's predictions are pulled toward the demonstrated outputs across repeated passes. With LoRA, only the small adapter weights move.
3. Held-out evaluation: Performance measured on examples the training never saw, against the baseline of the untuned model with a good prompt. Skipping the baseline is how teams tune their way to something prompting already achieved.
4. Versioned deployment: The adapter ships like any artifact: versioned, evaluated, revertible.

Two mechanics worth knowing beyond the basics:

5. Preference tuning (DPO): Instead of showing the model one right answer, you show it pairs, this response over that one, and train it toward the preferred side. SFT teaches by example; DPO teaches by taste, for qualities that are easy to compare and hard to specify, like helpfulness or restraint. Its breakthrough was simplicity: it replaced the reward-model-plus-reinforcement-learning pipeline that preference alignment previously required with one direct training step, and in practice teams run it after SFT, as a refinement stage rather than a rival.
6. Catastrophic forgetting: Tuning narrows the model toward the demonstrated behaviour, and pushed too hard it degrades general capability, following instructions worse outside the tuned lane. Careful data mixing and light-touch adapters exist precisely to hold that line.

Benefits of Fine-Tuning

1. Consistency without prompting: The format and tone are in the weights, steadier than instructions the model can drift from.
2. Small models, big-task performance: The routine 80 percent of a workload runs on a tuned small model at a fraction of frontier cost.
3. Shorter prompts: Behaviour baked into weights stops being re-explained per request, cutting tokens and latency.
4. Domain fluency: The conventions of clinical notes, legal drafting, or log formats become native rather than coached.

Where Fine-Tuning Is Used

1. High-volume structured tasks: Extraction, classification, and tagging where format consistency is the job.
2. Voice and tone: Outputs that must sound like your organization every time.
3. Domain-specific generation: Clinical, legal, and technical writing conventions.
4. Small-model deployment: On-premise and edge scenarios where a tuned compact model replaces API calls to a large one.

Common Mistakes With Fine-Tuning

1. Tuning to teach facts: The model will sound authoritative about your policies while reconstructing them imperfectly, and every fact change means retraining. Retrieval exists for exactly this.
2. Skipping the prompting baseline: A structured prompt with examples frequently matches a tuning run. If nobody measured the baseline, the tuning budget bought nothing provable.
3. Small or sloppy datasets: A few dozen inconsistent examples teach inconsistency. The dataset deserves the majority of the effort.
4. One tune, forever: Tasks drift, and a tuned model is a snapshot. Without scheduled re-evaluation, quality erodes invisibly.
5. Vocabulary inflation: Calling a tuning run "training our own model" sets budgets and risk assessments against the wrong reference class.

When You Should Not Fine-Tune

If the knowledge changes, prices, policies, inventory, anything with a shelf life, tuning bakes in staleness. Retrieval keeps it current without touching the model.

If prompting has not been tried seriously, structured instructions, few-shot examples, a strong base model, tuning is premature. The baseline might already be the answer, and it costs nothing to maintain.

And if volume is low, the economics rarely close. Tuning pays back through many cheap calls replacing many expensive ones. At a few hundred requests a day, the engineering time outweighs the token savings.