Fine-tuning

It is the most misunderstood option on the menu, and the misunderstanding is expensive. Teams routinely propose it when what they actually want is for the assistant to know their documents, which this does not reliably deliver. Understanding what it does change, behaviour, and what it does not, knowledge you can rely on, saves a project that would otherwise spend months producing a model that writes beautifully in your house style and still cannot tell you your own refund window. Where it does fit, it is genuinely powerful and cheaper than its reputation suggests.

Training continues from where the original left off. Rather than starting with a blank model, the process takes an existing one and shows it your examples, nudging its internal settings towards producing outputs like yours. Because it starts from something already capable, this needs far fewer examples and far less computing than the original training did.

The examples are the whole product. A typical set is pairs: this input, that desired output, several hundred to a few thousand of them, consistent in style and format. Assembling that set honestly is the bulk of the work, and inconsistency in it shows up directly as inconsistency in the result, because the model has no way of knowing which of two conflicting examples you meant.

What changes is disposition rather than knowledge. The reliable outcomes are stylistic and structural: tone, format, terminology, how the model handles a particular kind of request, whether it refuses or attempts something. Facts introduced this way are absorbed unevenly and cannot be relied on, which is the single most consequential thing to understand about the technique.

Cheaper variants are now standard. Rather than adjusting every internal setting, common methods adjust a small additional set and leave the original untouched, which cuts the cost and the storage substantially and makes it practical to keep several variants for different jobs. Most managed fine-tuning services use an approach of this kind whether or not they say so.

It can make a model worse at things you did not intend to change. Training hard on a narrow set of examples can erode general ability, a failure known as catastrophic forgetting. A model coached exclusively on terse support replies may become worse at long explanations it used to handle well, so evaluation has to cover what you were not trying to change.

Every underlying model change means doing it again. A fine-tune is tied to the specific model it started from, so when the provider releases a successor, your adjustments do not transfer. That is a recurring cost rather than a one-off, and it is the consideration most easily left out of the original business case.

Your examples are material you hand over, which makes this a data question as much as a technical one. A managed service means uploading them, so it is worth reading what the terms say about retention and about whether they may be used for anything else. That matters most where the examples are customer records, contracts, or anything covered by an agreement you signed with somebody else. Training on infrastructure you control avoids the question entirely, at the cost of running it yourself.

The order worth trying is almost always the reverse of the order people propose. Clear instructions first, then examples in the request, then retrieval for anything factual, and only then fine-tuning if the remaining gap is genuinely about consistent behaviour at volume. Each step is cheaper, faster to change and easier to explain than the next.

• Run an adapted model on your own hardware, where the adjusted version stays with you rather than being hosted by whoever supplied the original.

  Ollama

• Compare a general model against an adapted one on the same prompts through a single routing interface, which is the honest way to find out whether the adaptation earned its cost.

  OpenRouter

• Try the cheaper alternative first by putting examples of the house style directly in the request, and see how much of the gap that closes before committing to training anything.

  Claude

How many examples do I need to fine-tune a model?

Fewer than the technique's reputation suggests for behaviour, often several hundred to a few thousand consistent pairs. Quality and consistency matter far more than quantity: a small clean set outperforms a large contradictory one, because conflicting examples teach the model that both answers are acceptable. Assembling that set is usually the bulk of the work.

Will fine-tuning make the model know our products?

Not reliably. Facts introduced this way are absorbed unevenly and cannot be verified afterwards, so the model may answer correctly on Monday and confidently wrongly on Tuesday. For product knowledge, supplying the material with the question through retrieval is both more reliable and updated by editing a document.

Is fine-tuning expensive?

The training itself is usually modest with modern methods. The real costs are assembling and cleaning the examples, evaluating the result properly, and repeating the exercise when the underlying model changes. Those are people costs rather than computing costs, and they are the ones missing from most initial estimates.

Can fine-tuning make a model worse?

Yes. Training hard on a narrow set can erode general capability, so a model coached on terse replies may become worse at the long explanations it previously handled. Evaluation therefore has to cover what you were not trying to change, not only the task you were aiming at.

How do we know whether the fine-tune worked?

By holding back a set of examples the training never saw and comparing the adapted model against the original on exactly those, judged by people who know what good looks like. Comparing against a remembered impression of the old model is how teams convince themselves of improvements that are not there. Include a few tasks you were not trying to change.

What should we try before fine-tuning?

Clear instructions, then two or three examples inside the request, then retrieval if the gap is factual. Each is cheaper, faster to adjust and easier to explain than the next. Fine-tuning is the right answer when the remaining gap is consistent behaviour needed at a volume where per-request instructions have become costly.

• Fine-tuning continues training an existing model on your examples, so it needs far less data than the original.
• It reliably changes behaviour: tone, format, terminology and how a task is handled.
• It does not reliably add facts, and what it does absorb cannot be checked or updated without retraining.
• Narrow training can erode ability you did not intend to change, so evaluate beyond the target task.
• A fine-tune is tied to its base model, so a provider's next release means doing the work again.

• Ollama

  Runs adapted models on your own hardware, so the result stays with you.

• OpenRouter

  One interface for comparing a general model against an adapted one on the same prompts.

• Claude

  The cheaper first step: examples in the request, before any training is commissioned.