01The pattern

A team fine-tunes a model, the metrics look good, it ships, and within a fortnight the feedback is that it is worse than the prompt-engineered version it replaced. The instinct is to reach for a bigger base model or more epochs.

That instinct is usually wrong. In the cases we see, the weights are the one part of the system that behaved as specified. What failed was the specification.

This is worth saying plainly because the alternative is expensive: another round of GPU hours to fix a problem that was never in the GPU.

02It is the data, and specifically what the data encoded

Fine-tuning teaches the model to reproduce the patterns in your examples. That includes patterns you did not intend to teach.

• Artefacts of how the data was collected. If your examples came from support tickets written by three agents, the model learns those three writing styles — including their habits of hedging, or of closing tickets abruptly.
• Answers that were correct in context you did not include. A response that made sense given an attached document becomes a confident fabrication when the document is not in the prompt.
• Label noise that correlates with something. Random noise mostly averages out. Noise that correlates with a class, a source or a time period becomes a learned bias.
• Length as a proxy. If your good examples are systematically longer than your bad ones, you may have taught verbosity rather than quality.

The diagnostic is cheap: read a random hundred examples yourself, and ask of each one what a model could learn from it other than what you intended. This exercise finds more problems per hour than any hyperparameter sweep.

03Evaluation that did not predict anything

The second failure is an evaluation that improves while the product gets worse. Three ways that happens:

The held-out set came from the same pipeline as the training set. It shares the collection artefacts, so it rewards learning them. A model that overfits your data source scores well and generalises badly.

The metric is a proxy for a proxy. Token overlap against a reference answer measures similarity to one phrasing, not correctness. A model can score worse for being right in different words.

An LLM judge with a shared bias. Using a model to grade outputs is practical, but if the judge prefers a house style and your fine-tune learned that style, the score rises without the answers improving.

04Distribution shift at the door

Training inputs are clean because someone cleaned them. Production inputs are what users type.

Typos, mixed languages, pasted formatting, half-finished sentences, questions outside the intended scope, and prompt-injection attempts all arrive on day one. A model trained only on well-formed inputs has no learned behaviour for any of them, and its failure mode is usually confident nonsense rather than a refusal.

The mitigation is not more training data; it is including realistic mess in the data you have, and deciding explicitly what should happen for inputs outside scope. That decision is a product decision, and skipping it does not remove it — it just means the model makes it for you.

05Latency and cost were never in scope

A fine-tune that improves answers and triples time-to-first-token can be a net loss for an interactive product. This gets discovered after launch surprisingly often, because training and serving are usually planned by different people at different times.

Two specifics worth settling before you train:

What latency does the product need? If the answer is interactive, streaming behaviour and time-to-first-token matter more than total generation time, and that shapes your serving stack and quantisation choices.

How many concurrent users, at what context length? This decides your memory ceiling long before it decides anything else. Our post on how the KV cache sets your user ceiling works through the arithmetic; the point here is that the answer constrains what you can deploy, so it belongs in the plan rather than in the post-mortem.

06Nobody owns the model after launch

The last failure is organisational. A fine-tune is a dated artefact: it encodes the data, the product scope and the user behaviour of the week it was trained. All three drift.

Without an owner, nobody notices the drift, nobody maintains the evaluation set, and nobody decides when to retrain. The model does not degrade suddenly — it degrades quietly, and the first signal is usually a support complaint rather than a metric.

What ownership means concretely: someone watches a small set of production samples weekly, keeps the hand-built evaluation set current as scope changes, and holds the decision on retraining. That is a modest amount of work, and it is the difference between a model that ages and one that rots.

07A pre-launch checklist

None of these needs a GPU. All of them are cheaper now than after a launch.

If you would like a second opinion on a plan before you commit GPU hours to it, describe the workload: contact@vijaycloud.com.