Fine-tuning

What it actually is

A model arrives already trained on an enormous amount of text. Fine-tuning continues that training on a much smaller set of examples you supply, nudging the model's internal settings toward the pattern your examples demonstrate. The result is a new, private version of the model that leans the way you trained it.

Note the shape of that: you are not adding a document to a library the model consults. There is no library. The examples are absorbed into the same diffuse statistical machinery that produced every other tendency the model has, which is precisely why the results are strong for some purposes and treacherous for others.

What it's genuinely good at

The wins are real, and they cluster tightly around form and consistency rather than knowledge. OpenAI's own guidance describes the use cases as classification, nuanced translation, generating content in a specific format, and correcting instruction-following failures, so that a model will "consistently format responses in a certain way or handle novel inputs."

• Rigid output formats. When every response must fit a schema exactly, thousands of times, demonstrating the format beats describing it.
• Classification at volume. Sorting things into your categories, using your judgement calls, including the awkward edge cases a prompt would need paragraphs to explain.
• A specific voice or house style. Style is far easier to show than to specify, and this is the clearest case where examples outperform instructions.
• Making a smaller model punch above its weight on one narrow task. Often the strongest commercial case: train a cheaper, faster model to handle the one thing you do a million times, rather than paying a frontier model to do it.
• Instructions that keep getting ignored. When a prompt has grown to a page of rules and the model still drifts, examples enforce what prose stopped enforcing.

Why it fails at teaching facts

This is the part worth understanding mechanically, because the failure is not obvious and the pitch for it is seductive.

The facts go in diffuse, not indexed. Your documents don't get stored anywhere retrievable. They shift the model's tendencies slightly, competing against everything it learned during original training, which was vastly larger. The model comes out more inclined to produce text like yours, which is not at all the same as knowing your specifics reliably.

There is nothing to cite. A retrieval system can show you the passage it used, so you can check it. A fine-tuned model produces an assertion with no provenance. On a site's worth of internal policy, that difference is the difference between a checkable answer and a confident one. → Hallucination

You cannot correct one fact. A wrong figure in a retrieval corpus is a one-line edit. A wrong figure baked into weights requires assembling a corrected dataset and training again. Facts change constantly; weights do not update themselves.

It creates a second staleness problem on top of the first. Your tuned model is frozen at the moment you trained it, and it is built on a base model that will be superseded. When the better base model ships, your tuning does not come with it: you retrain, re-evaluate, and re-deploy, or you stay on the older model while the frontier moves. Every fine-tune is a standing maintenance commitment, and that cost is invisible on day one. → Training cutoff

The order to try things

Cheapest and most reversible first. Most projects that reach for fine-tuning stop somewhere earlier once they actually work through this order:

1. Write a better prompt. Unglamorous, and frequently sufficient. OpenAI's guidance says outright that "the prompt engineering process may be all you need in order to get great results for your use case."
2. Put examples in the prompt. A handful of demonstrations of exactly what you want. This is fine-tuning's effect without the commitment, and it is instantly editable.
3. Give it the material. If the gap is knowledge rather than behaviour, retrieval is the answer and fine-tuning is not.
4. Then fine-tune, if a specific behaviour still won't hold at the volume you need, or you want a smaller model to do one job cheaply.

A useful diagnostic: if you can get the behaviour you want by pasting three good examples into the prompt, fine-tuning will probably work and probably isn't necessary yet. If pasting examples doesn't help at all, fine-tuning usually won't either, and the problem is elsewhere.

The costs nobody quotes

The training bill is usually the smallest line. The real costs:

• Building the dataset. This is the project. Assembling examples that are correct, consistent and genuinely representative is slow human work, and every inconsistency in them teaches the model to be inconsistent.
• Knowing whether it worked. You need a held-back set of cases and an honest comparison against the un-tuned model with a good prompt. Skipping this is how teams end up maintaining a tuned model that never beat the baseline.
• The upgrade treadmill. As above, and it recurs on someone else's release schedule rather than yours.
• Lost generality. A model tuned hard toward one behaviour can get worse at things it used to handle fine. If it only ever does the one job, that's a fair trade. If it drifted into general use, it is a trap.

Sources

The described use cases (classification, nuanced translation, generating content in a specific format, correcting instruction-following failures) and the quoted line that prompt engineering "may be all you need" come from OpenAI's model optimization guide, fetched 11 August 2026. Worth noting what that documentation does not claim: knowledge acquisition is absent from its list of benefits. The argument for why facts specifically fail to stick is mechanical reasoning from how training works, not a vendor statement.

Read first → RAG and retrieval · Related → Prompt caching · All → Concepts