# Fine-tuning

Fine-tuning is extra training that adapts an existing AI model to a particular task or output.

Source: https://rodamora.com/glossary/fine-tuning
Updated: 2026-08-09

---

Fine-tuning is extra training that changes how an existing model responds to a repeated kind of work. It fits a service firm when the task runs often, the standard stays stable, and ordinary instructions keep failing in the same measured way. It is a poor first move when the real problem is missing client data, an old policy, or an unwritten process. OpenAI recommends building an eval before tuning and starting with 50 well-made demonstrations. That gives you a practical check. If your team cannot agree on dozens of correct examples and score a new answer against them, the firm has not defined good work well enough to tune a model. The next job is to set that standard.

## What does fine-tuning change?

Fine-tuning changes a model's behavior. It starts with an existing model instead of building a foundation model from nothing.

In supervised fine-tuning, each training example contains a request and the answer you wanted. Repeating that pattern across a dataset adjusts the model so the desired response becomes more likely. [OpenAI lists](https://developers.openai.com/api/docs/guides/supervised-fine-tuning) classification, nuanced translation, fixed-format content, and recurring instruction-following failures as suitable uses.

Imagine a firm that turns call notes into project briefs. The base model understands the notes, but it keeps putting risks in the scope section and leaves out the named owner. A tuned model can learn the firm's brief structure from approved examples. It can learn that a risk belongs under one heading and an owner under another.

Now change the problem. The model uses last quarter's price or an old cancellation rule. Those facts belong in current context, not in training. A fine-tuned model can absorb facts from examples. Updating those facts later means changing the dataset and training again. Current operating knowledge needs a source the system can retrieve at run time.

Fine-tuning helps a model repeat a stable behavior. Context supplies the facts the current job depends on.

## When is fine-tuning the right tool?

Fine-tuning earns its cost after four conditions hold.

**The task repeats.** One unusual proposal does not justify a custom model. Hundreds of similar classifications, summaries, or structured drafts might. The repeated volume gives the training work a chance to repay its cost.

**The standard is stable.** Three senior people should grade the same output in much the same way. If they disagree, the training set will preserve that disagreement instead of resolving it.

**You have approved examples.** OpenAI allows as few as 10 examples, reports improvement around 50 to 100, and recommends starting with 50 well-crafted demonstrations. [Google's tuning guidance](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/tuning) sets a similar practical bar: roughly 100 or more labeled examples for a task where advanced prompting has not been enough.

**You already have a test.** OpenAI's instruction is direct: “Good evals first.” A baseline shows what the ordinary model gets right, where it fails, and whether tuning improved the result. Without that comparison, a tuned answer may look more consistent while becoming less correct.

These conditions put the hard work before the training job. The useful asset is the set of real inputs, approved outputs, and written checks that define good work. [Document the process first](https://rodamora.com/blog/document-the-process-first-or-the-agent-scales-the-chaos). Training cannot settle a standard the firm has never settled for itself.

## When should you use prompts, context, or retrieval instead?

Use the smallest change that fixes the measured failure. Most firms have cheaper places to work before they alter a model.

| If the model is missing... | Fix this first | Why |
|---|---|---|
| A clear instruction or output format | Prompt | The rule can travel with each request |
| Current client facts, prices, or policies | Context or retrieval | The information can change without retraining |
| A fixed sequence of steps and handoffs | AI workflow | The order belongs in the process, not the model |
| A stable behavior across many similar cases | Fine-tuning | Examples can make the response more consistent |

A [prompt](https://rodamora.com/glossary/prompt) is right when the instruction is short enough to state and the model follows it reliably. Add a few examples when words alone leave room for interpretation. Google recommends starting here to establish the best prompt and a baseline before tuning.

[Context](/glossary#context) and retrieval are right when the answer depends on information outside the model. Examples include the signed agreement, today's price list, approved service scope, or a client's last three decisions. That material can change tomorrow. The system should fetch the current version tomorrow.

An [AI workflow](https://rodamora.com/glossary/ai-workflow) is right when the job has a fixed route. Pull the record, check required fields, draft the response, send uncertain cases to a person, then write the result back. Fine-tuning can improve one model step inside that route. It does not create the route.

Fine-tuning becomes the candidate when those pieces are sound and the model still makes the same kind of mistake. The failure should appear across a test set. It should also stay stable enough that fixing it will matter after the next policy update.

## How do you know fine-tuning worked?

Run the base model and the tuned model against examples neither saw during training. Score both with the same [eval](https://rodamora.com/glossary/eval).

Correctness comes first. For a project brief, the scope should match the call, risks should sit in the right section, every decision should have an owner, and unsupported promises should be absent. Then measure the operating effect. Count how often a person changes the draft, how long the check takes, what each accepted output costs, and how often work returns for correction.

Keep the test set separate from the training examples. A model can learn the examples it saw without learning the general pattern you need. Testing on the training set is like handing someone the answer key and calling the result competence.

Training does not guarantee improvement. A paper published at ICML in 2025 found that one instruction-tuned OLMo-1B checkpoint trained longer before fine-tuning ended [more than 2% worse on several downstream benchmarks](https://proceedings.mlr.press/v267/springer25a.html) than a less-pretrained checkpoint. That result does not predict what your model will do. It does show why the outcome must be measured.

Include cost in the comparison. A tuned smaller model may produce an acceptable brief with a shorter prompt, while a larger general model needs more instructions and costs more per run. The winning choice produces an accepted unit of work at the right quality. [Your AI employee's rate card](https://rodamora.com/blog/your-ai-employee-has-a-rate-card-you-set-it) includes model calls and human review.

## What does a tuned model cost to own?

The training run is the first bill. The dataset becomes a maintained operating asset after that.

Someone has to remove weak examples, add new failure cases, keep private data out of the wrong place, and record which dataset produced each model. That person also has to rerun the eval when the model or the work changes. A new base model is a new candidate. It may beat the tuned model without training, or it may need a new tuning pass. The comparison decides.

Delivery changes create the same obligation. If the firm changes its proposal structure, approval rule, or definition of an acceptable risk, yesterday's approved output can become today's bad example. Training data goes stale even when the underlying software does not.

This ongoing work sets the limit. Fine-tuning fits stable, repeated work with many approved examples and enough volume to repay maintenance. It does not fit five custom deliverables a month, a policy library that changes every week, or a process the firm still argues about.

## Where does fine-tuning sit on the Delivery Model Ladder?

Fine-tuning belongs at Stage 1, Enhanced, on the [Delivery Model Ladder](https://rodamora.com/delivery-model-ladder). It can make one AI-assisted task faster, cheaper, or more consistent while a person still starts the work and owns the surrounding process.

Stage 2 begins when the firm builds the workflow around that model step: the trigger, current context, tool access, approval point, failure route, and final record. A tuned model may run inside that workflow. Tuning alone does not move the firm up a stage.

That distinction is part of the [Production Gap](https://rodamora.com/production-gap). A model that produces a clean sample is a component. Production requires the firm to supply current information, test the result, handle exceptions, and maintain the system after the original builder moves on.

## Quick answers

**Is fine-tuning the same as training a model from scratch?** No. Training from scratch creates a model from a large initial dataset. Fine-tuning starts with an existing model and adjusts it for a narrower task or behavior.

**Can I fine-tune a model on company documents?** You can, but changing company facts usually belong in a source the system retrieves when needed. Fine-tune stable behavior. Retrieve the current policy, price, contract, or client record.

**How many examples do I need?** Current vendor guidance starts around 50 to 100 strong, representative examples. The useful number depends on the task. Fifty approved examples that match production beat a larger pile of inconsistent output.

**Does fine-tuning replace an eval?** No. The eval comes first, measures whether tuning helped, and catches regressions when the model, dataset, or delivery standard changes.