Fine-Tuning
Fine-tuning is continuing to train a pre-trained model on a smaller, task-specific dataset so that it adapts to a domain, a format, a style or a task — a language model on a company's ticket categories, a vision model on its document types — while keeping the general capability pre-training gave it. Parameter-efficient methods (LoRA) train a few million added weights instead of billions; the choice against prompting or retrieval turns on consistency, volume and how narrow the task is.
- Also known as
- Fine-tuned model, Parameter-efficient fine-tuning, LoRA, Domain adaptation
- Used at
- classification and extraction at high volume, a company's output formats and tone, domain vocabulary a general model lacks, small models that must run cheaply or on-device, and vision tasks on the company's own images; not for adding knowledge that changes, which retrieval handles better
- Binding
- the base model's licence (open-weight terms on commercial use and redistribution; API vendors' terms on fine-tuning through their services and on using outputs to train other models); data protection on the fine-tuning data; the EU AI Act treats a substantial modification as making the modifier a provider
- Typical mechanics
- full fine-tuning updates all weights at a low learning rate for a few epochs; LoRA freezes the base and trains low-rank adapter matrices in the attention layers (rank 8–64, a fraction of a percent of the parameters); the fine-tuned adapter is a small file that loads on the base; instruction-format data for language models, labelled images for vision; evaluation on a held-out set before and after
- Typical numbers
- a few hundred to a few thousand examples for a narrow task; hours on one GPU with LoRA; tens to hundreds of dollars in cloud cost; accuracy gains of several points over prompting on narrow tasks and cost per call a tenth or less when a small fine-tuned model replaces a frontier one
- Parties
- the data scientists and engineers, the labs and communities providing base models, the API vendors offering managed fine-tuning, and the reviewers who ask what data trained the adapted model
How fine-tuning works in practice
A payments company classifies 200,000 support tickets a month into 40 categories. A frontier model with a few-shot prompt reaches 86% accuracy at $0.02 per ticket — $4,000 a month and a drift between runs the reporting team dislikes. The team fine-tunes an open 8-billion-parameter model with LoRA on 6,000 tickets labelled by the support leads: three hours on one GPU, $14 of compute. The fine-tuned model reaches 93% on a held-out set, runs on a GPU the company already has at $0.001 per ticket, and produces the same label for the same ticket every time. The adapter is 40 MB; a new category means 200 more labelled examples and a retrain. The company evaluates every retrain on the held-out set and keeps a frontier model in reserve for the 5% of tickets the small model flags as uncertain.
The decision framework has settled. Prompting first: it is free to try and often enough. Retrieval when the task needs knowledge the model lacks or that changes — policies, documents, the customer's data — because fine-tuning bakes knowledge in as of training day and retrieval reads it live. Fine-tuning when the task is narrow, the volume is high, the format must be exact, or the model must be small; and when the company has, or can label, a few thousand good examples. The failures are known: fine-tuning on unedited transcripts teaches the agents' mistakes; too many epochs at too high a rate makes the model forget its general ability (catastrophic forgetting); no held-out evaluation means the gains are imagined; and fine-tuning on data generated by a model whose terms forbid it is a licence breach. For a buyer, a fine-tuned model is a real capability whose value is the labelled data and the evaluation behind it; the base model is someone else's.
For a fintech, fine-tuning is how a general model becomes the company's own at a cost that fits a team of two; for an acquirer, the fine-tuning data and the evaluation results are what to read, and the base model's licence is what to check.
Example
A lender's document pipeline uses a frontier vision-language model to extract fields from bank statements at $0.40 per document, 1.2 million documents a year — $480,000. Accuracy 94% on its evaluation set. The team fine-tunes an open vision-language model (7 billion parameters) with LoRA on 4,000 statements labelled by its operations team over three weeks: accuracy 95% on the same evaluation set, cost per document $0.03 on self-hosted GPUs — $36,000 a year, plus $60,000 of labelling and engineering once. The frontier model remains for the 6% of documents the fine-tuned model marks low-confidence. Annual saving: about $400,000. The model-risk file records the base model's licence (permissive), the training data's source and consent basis, the held-out evaluation, and the retraining trigger when the evaluation drops below 93%.
Common mistakes
- Fine-tuning to add knowledge that changes; retrieval does that. - Training on unedited data and learning its errors. - Too many epochs, too high a rate, and a model that forgot its general ability. - No held-out evaluation before and after. - Ignoring the base model's licence and the terms of the model whose outputs were used as training data.