Fine-tuning
Also: model fine-tuning, supervised fine-tuning, SFT
What is Fine-tuning?
Fine-tuning is further training of an existing language model on your own examples to change its behaviour, style or task performance; it teaches the model how to respond, not what your documents currently say.
What Fine-tuning means
Fine-tuning takes a pre-trained model and continues training it on a curated dataset of inputs and desired outputs, adjusting either all weights or, more commonly, a small set of adapter weights (LoRA and similar methods). The result is a model that follows a format more reliably, adopts a tone, handles a domain's jargon, or performs a narrow task (classification, extraction, a specific output schema) with fewer instructions and fewer tokens per call.
It is frequently confused with RAG. Fine-tuning does not reliably inject facts, and the facts it does absorb go stale the moment your documents change. RAG supplies current facts at query time; fine-tuning shapes behaviour. The usual production pattern is RAG for knowledge with prompt engineering for behaviour, and fine-tuning only when evals show the prompt-based approach cannot hit the bar or costs too much per call.
Fine-tuning is also not free of ongoing work: it needs a clean labelled dataset, an eval suite to prove the gain, hosting for the resulting model, and a plan for re-tuning when the base model is deprecated.
Who it really matters to
- CTO / Head of Engineering: Fine-tuning creates a model artefact you must host, version and re-train; decide it on measured eval gain, not on instinct.
- CFO: A tuned smaller model can cut per-call inference cost substantially at volume, which is the most common financial case for it.
- Data lead: The labelled dataset is the real asset; its quality determines the result and it remains valuable across base-model changes.
- Compliance officer: Training data may contain personal data; consent, retention and residency rules apply to the training set as much as to production.
Why it exists
Prompting can only push a general model so far: long instructions cost tokens on every call, some formats and domain conventions never become reliable, and a large model may be needed for a task a small one could learn. Fine-tuning exists to bake behaviour into the weights so the model does the task natively, faster and cheaper. The trade-off is upfront data work, a maintained model artefact, and the risk of solving a knowledge problem with the wrong tool. The stance we recommend is RAG first, prompt second, fine-tune when evals prove the need.
Where it is applied
- Tuning a small open-weight model to classify support tickets in a SaaS helpdesk at a fraction of the cost of a frontier API
- Extraction of fields from KYC and loan documents in a consistent schema for an NBFC
- Adopting a retailer's brand voice for generated product descriptions and WhatsApp replies
- Structuring clinical notes into a hospital's standard sections while running inside its own infrastructure
- Grading short-answer responses against a rubric for an education platform
Is Fine-tuning a skill?
Technique / practiceAn ML engineering practice requiring dataset curation, training runs and eval-based validation. Eazyware's AI/ML Development service covers it, and we recommend it only after RAG and prompt-based approaches have been measured against the same golden set.
Eazyware service that covers it: AI/ML Development. Starting prices are on the pricing page.
Frequently asked questions
Should we fine-tune a model on our documents so it knows our business?
Usually no. Fine-tuning does not reliably store facts and they go stale as documents change. Use RAG to supply current documents at answer time, and consider fine-tuning only to change format, tone or task behaviour.
How much data does fine-tuning need?
For behaviour and format tasks, a few hundred to a few thousand high-quality examples is often enough with adapter methods. Quality and coverage of edge cases matter far more than raw volume.