Fine-tuning

Where it sits on the ladder

There are four ways to make a model behave the way your product needs, and they differ by roughly an order of magnitude each in cost, in the time to try something, and in how much you have to own afterwards. The rule that keeps teams out of trouble is simple: never climb a rung you have not been pushed off. Most projects that fine-tuned early discover afterwards that a better prompt and a retrieval step would have got them the same result in an afternoon.

• Prompting

  Minutes to change, nothing to own. Fixes format, tone and most behaviour. Costs input tokens on every call, forever.

• Retrieval

  Days to build. The only way to give the model facts it can cite, update and have restricted per user.

• Fine-tuning

  Weeks, mostly spent on data. Moves consistent behaviour into the weights and shortens every prompt that follows.

• Continued pretraining

  Months and a serious budget. Reserved for a domain whose language the base model genuinely does not speak.

What the methods differ on

Two distinctions cover almost everything you will meet. The first is how much of the model you actually change. Full fine-tuning updates every weight, needs the hardware to hold optimiser state for the whole model, and produces a complete new model to store and serve. Parameter-efficient methods — LoRA is the one you will meet by name — freeze the original weights and train a small set of additional ones alongside, typically a fraction of a percent of the total. The result is nearly as good on most adaptation tasks, trains on hardware you can rent by the hour, and produces an adapter measured in megabytes that can be swapped per customer on top of one shared base model. For product work this is the default, and full fine-tuning is the exception that needs justifying.

The second distinction is what you show the model. Supervised tuning shows it input and the correct output, and it is the right tool whenever a correct answer can be written down — a classification, an extraction, a document in your house format. Preference tuning shows it two answers and which one a human preferred, and it exists for the cases where you cannot write the right answer but can recognise it: tone, helpfulness, how firmly to refuse. Preference data is much more expensive to collect and is worth reaching for only after supervised tuning has taken you as far as it goes.

The dataset is the project

The training run is a command that takes a few hours. Everything that determines whether it worked happens before it, in the dataset, and teams consistently budget this the wrong way round. A few hundred genuinely good examples beat tens of thousands of scraped ones, because the model learns exactly what you show it — including the inconsistencies. Two annotators who disagreed about the same case teach the model to be inconsistent in precisely that place, so agreeing the labelling rules in writing before anyone labels anything is not process for its own sake.

The dataset also has to look like production, which sounds obvious and is routinely violated. Real input is messy: typos, mixed languages, pasted email signatures, empty fields, questions the system should refuse. If every training example is a clean, well-formed request, the model learns that the world is clean and behaves unpredictably the first time it is not. Include the awkward cases and the refusals deliberately, in roughly the proportion they occur.

Hold examples back before you start, and never train on them. Without a held-out set you have no way to distinguish a model that learned the task from one that memorised your examples, and the second looks perfect on everything you measured. The comparison that matters is not the tuned model against nothing — it is the tuned model against the best prompt you managed on the base model, on the same held-out cases. If that gap is small, you have just bought a maintenance obligation for nothing.

How this shows up in real delivery

The bill people forget is the one that arrives later. A tuned model is pinned to the base it was trained on, so when the provider ships a better base — which now happens several times a year — your tuned model does not inherit any of it. You are choosing between staying on an ageing base and repeating the whole exercise: retrain, re-evaluate, re-deploy. Before starting, work out how often you are willing to do that and who owns it, because a tuned model with no owner quietly becomes the oldest component in the system.

Serving splits into two very different situations. A hosted provider takes your dataset, returns a model id, and the rest of your code is unchanged — you pay a premium per token and you are done. Self-hosting an open-weights model with your adapter gives you control over data residency and unit cost at high volume, and hands you a GPU fleet to run, with capacity planning, batching, quantisation trade-offs and an on-call rota. That second path is a platform commitment, not a deployment step, and it is worth naming as such before the decision is made by default.

One behaviour to watch for after any training run: a model tuned hard on a narrow task gets worse at things it used to do. Ask a model trained only to emit classification labels to explain its reasoning and you may get a label. That is the expected consequence of pushing the weights toward one distribution, and it is caught by keeping a handful of general cases in the evaluation set rather than measuring only the task you trained for.

Where it degrades

• Fine-tuning before a serious attempt at prompting and retrieval, which usually would have been enough.
• Training on documents to teach facts, producing fluent answers with quietly wrong details.
• No held-out set, so a memorised dataset is indistinguishable from a learned task.
• Comparing the tuned model against nothing instead of against the best prompt on the base model.
• Inconsistent labels, which teach the model to be inconsistent in exactly those places.
• Clean training data for a messy production input, so the first malformed request behaves unpredictably.
• No plan and no owner for retraining, leaving the tuned model pinned to a base nobody wants to be on.

When to use it

Related pages

• DevelopmentRAG ArchitectureRetrieval-augmented generation (RAG) is how a model answers questions about data it was never trained on: find the relevant passages first, put them in the prompt, and require the answer to come from them. That makes RAG a search system with a language model on the end — and it means almost every wrong answer is a retrieval failure, not a generation one. This page covers both pipelines, how to measure retrieval separately, and the permission problem that turns a demo into an incident.
• DevelopmentPrompt EngineeringPrompt engineering is the work of writing the instruction a language model acts on. A prompt is a specification, not an incantation. The phrases that get traded as tricks work only because they add information the model did not otherwise have, and the ones that do not add information do nothing at all. This page covers what a prompt is made of, which techniques genuinely change the output, how to tell whether a change helped, and why untrusted text in a prompt is a security boundary rather than a wording problem.
• DevelopmentLLMOpsLLMOps is the practice of running a feature built on a language model in production, and it exists because everything that makes software releasable — a test that fails, a diff that explains a change, a rollback that restores yesterday — assumes the same input gives the same output. LLM features break that assumption, so the practices have to be rebuilt around it. This page covers what replaces the test suite, what the deployable artefact actually is, what to record on every call, and how cost and latency behave once real traffic arrives.