Fine-tuning

Fine-tuning takes an already trained language model and trains it further on your own examples. The goal is not new knowledge but dependable behaviour: one task solved in a fixed format, in a particular tone, or according to your conventions.

How does fine-tuning work?

You supply example pairs of input and desired output. A training run adjusts the model's weights so it reproduces those patterns. The result is your own variant of the model, which you then call exactly as you called the original.

The number of examples needed is smaller than most people expect. For a clearly bounded task, a few hundred good pairs will often do. Consistency matters more than volume: if the examples contradict each other, the model learns the contradictions too.

Most fine-tuning today uses parameter-efficient methods that train a small addition rather than the whole model. That is cheaper, faster, and can be switched off again.

When is fine-tuning worth it?

When a behaviour is needed often and identically. A model that always translates service requests into the same ticket schema, or writes product descriptions consistently in your voice, improves more from examples than from ever-longer instructions.

It also pays when a very long prompt is being sent every single time. Whatever sits in the training no longer has to travel in the context window, which cuts both cost and latency.

It is not worth it when what is actually missing is knowledge. Training facts into a model is expensive, hard to verify and out of date with the next document revision. RAG is the right tool for that.

The case against

A fine-tuned model is another component with its own lifecycle. It has to be versioned, evaluated, and retrained when you move to a newer base model. That work recurs indefinitely.

Fine-tuning also relocates errors rather than removing them. A model taught to always produce an answer in the right format will produce one when it does not know the answer either. A hallucination looks tidier after training than before, which makes it harder to catch.

Hence the order of operations: exhaust prompting and context first, then RAG, and fine-tuning last. There is a longer treatment in RAG vs fine-tuning.

What you need for it

The effort sits almost entirely in the data rather than the training. The training run is a matter of hours; the preparation is a matter of weeks.

What is needed is example pairs from real cases, not invented ones. Often they already exist: resolved tickets, approved quotes, edited copy. The value of that collection lies in how carefully it gets reviewed.

Alongside it you need a test set that is held back from training. Without withheld examples there is no way to tell whether the model learned something or is just reciting the training data.

And you need a decision about inconsistency. If three people answered the same request differently, which version is correct has to be settled first. That settlement is the real benefit of the preparation, whether or not you end up training anything.

In practice: if you cannot assemble the examples, do not train. A project that stalls at this point would not have had a checkable definition of success with a finished model either.