Fine-tuning takes a model that's already been trained on a broad, general dataset and continues training it on a smaller, more specific one. Instead of training a model from scratch, it adjusts the existing learned weights toward the behavior, style, or domain that the new dataset represents. It's a real, useful technique, but as covered in prompt engineering vs. fine-tuning vs. RAG, it's also the option to reach for last, after the cheaper alternatives have been genuinely ruled out.
The actual process, at a practical level
Prepare a genuinely high-quality dataset
Fine-tuning requires a dataset of examples that demonstrate the specific behavior, format, or knowledge you want the model to learn. The same discipline covered in data labeling applies here: the quality and consistency of this dataset determine the quality of the fine-tuned result. A smaller, genuinely high-quality dataset generally outperforms a larger, inconsistent one.
Choose a base model to fine-tune
The base model's existing capabilities matter, because fine-tuning adjusts an already capable model rather than teaching it from nothing. Choosing a base model that's reasonably well suited to the target task deserves real consideration before fine-tuning starts.
Run the actual training process
The fine-tuning process adjusts the model's weights based on the new dataset, typically using far less compute than the original training run, because it builds on an already trained foundation rather than starting from random weights. Many teams use parameter-efficient methods such as LoRA, which train a small set of added weights instead of updating the whole model, cutting cost and memory requirements further.
Evaluate rigorously against real, held-out examples
The same evaluation discipline covered in building a real evaluation harness applies directly to a fine-tuned model. Test against examples the model wasn't trained on, and check both for improvement on the target behavior and for unintended regression in general capability, which careless fine-tuning can cause.
What fine-tuning is actually good for
- A very specific, consistent output format that in-context instruction alone doesn't reliably produce across many examples.
- Domain-specific terminology or style that needs to be reproduced more consistently than describing it in a prompt each time achieves.
- A narrow, well-defined task performed at high volume, where the upfront fine-tuning investment pays off across enough repeated use to be worth the cost.
What fine-tuning is a poor fit for
- Teaching a model new facts. This is generally better solved with retrieval-augmented generation, because fine-tuning doesn't reliably give a model precise, current, or easily updatable factual knowledge the way retrieval does.
- Problems a better prompt could solve. A better prompt is nearly always cheaper and faster to test first.
- Use cases needing frequent updates. Each meaningful change to a fine-tuned model's target behavior requires re-running fine-tuning, which is slower and more expensive than updating a retrieval index or a prompt.
How we approach this
We fine-tune only after ruling out prompt engineering and retrieval for a specific problem, with rigorous evaluation against held-out data and honest awareness of the portability tradeoff. Fine-tuning is a real, sometimes necessary tool, not a default to reach for because it sounds more sophisticated.