Fine-tuning takes a model that has already been pretrained on massive general-purpose data. Training then continues on a much smaller, curated dataset to specialize the model's behavior.

Fine-tuning starts from learned weights and updates them with a much smaller, task-focused dataset. It needs far less data and compute than pretraining.

The practical differences are:

• Scale: trillions of tokens versus thousands of curated examples.
• Objective: usually the same next-token prediction loss, but applied to task-specific input-output pairs.
• Learning rate: much lower than pretraining, so behavior changes without overwriting broad capabilities.
• Goal: pretraining builds raw capability; fine-tuning shapes behavior such as style, output format, domain vocabulary, and task reliability.

Almost no application team pretrains from scratch. In practice, customization means prompting, retrieval-augmented generation (RAG), or fine-tuning, and fine-tuning itself is usually parameter-efficient (LoRA-style) rather than updating every weight.

Think of it as an escalation ladder ordered by cost and iteration speed:

• Prompting (system prompts, few-shot examples, structured output settings): always the first resort.
• RAG: reach for it when the problem is knowledge. Fresh, proprietary, or per-user data; the need for citations; content that changes daily.
• Fine-tuning: reach for it when the problem is behavior. Consistent style or format, domain vocabulary, or reliable tool calling. Also making a small cheap model do what a big model needs a huge prompt to do.
• Continued pretraining or training from scratch: only for deep domain or language adaptation with billions of tokens (say, a genomics or low-resource-language model).

In short: RAG fixes what the model knows; fine-tuning fixes how it behaves.

A reliable approach is insisting on an evaluation set first and exhausting the cheaper rung against that eval. Only move down the ladder when the current rung demonstrably fails. This is because each step down adds cost, latency of iteration, and operational burden.

Supervised fine-tuning (SFT) is ordinary gradient-descent training applied to a pretrained model on labeled input-output pairs. Mechanically:

1. Each example (typically a chat conversation) is rendered into a token sequence using the model's chat template, with special tokens marking roles and turn boundaries.
2. A forward pass computes the model's predicted probability for each next token, and cross-entropy loss compares predictions to the actual tokens.
3. Backpropagation computes gradients, and an optimizer (almost always AdamW) updates the weights: all of them in full fine-tuning, or a small adapter in parameter-efficient methods.
4. Repeat for a few passes over the dataset, using a small learning rate, a short warmup, and a decay schedule.
5. A held-out validation split is scored periodically to catch overfitting.

The objective is identical to pretraining; what changes is the data, the scale, and the learning rate.

Most trainers accept JSON Lines (JSONL): one JSON object per line, with each object holding a complete chat conversation. The exact field names may vary, but the structure is similar:

{"messages": [
  {"role": "system", "content": "You are Acme's billing support assistant. Reply in under 120 words."},
  {"role": "user", "content": "I was charged twice this month."},
  {"role": "assistant", "content": "I'm sorry about that. I can see duplicate charges are usually authorization holds..."}
]}

Practical rules that matter more than the syntax:

• Include the system prompt you will actually use in production, verbatim. The model learns the pairing of that prompt with the desired behavior.
• Assistant messages are the target answers. They must match the style, format, and quality you want. The model can learn their flaws as easily as their strengths.
• Multi-turn conversations are fine and often valuable; trainers mask the loss so only assistant turns are learned.
• For tool-use fine-tuning, include the tool schemas and assistant tool-call messages in the same structure the runtime will produce.

The deeper point: dataset design is the product spec. Every quirk in your examples, from greeting phrasing to how errors are handled, becomes model behavior.

Fine-tuning works best when you need consistent behavior, not a store of changing facts:

• Style and tone: a support voice, legal register, brand personality, or strict reading level, applied every time without prompt gymnastics.
• Format adherence: always-valid JSON against a schema, specific markdown structures, diff formats, or domain-specific notations that prompting produces.
• Domain vocabulary and conventions: using clinical, legal, or internal jargon correctly and preferring your organization's terminology.
• Task specialization: classification, extraction, routing, summarization in a fixed shape, where a tuned small model often beats a prompted large one.
• Prompt compression: baking a 3,000-token instruction block into the weights, cutting cost and latency on every request.
• Latency and cost: distilling a narrow capability from a frontier model into a 4-9B parameter model.
• Implicit rules: behaviors that are easy to demonstrate with examples but hard to articulate as instructions, like judgment calls in moderation.
• Reliability of tool calling in agentic workflows.

The common thread: you have examples of what good looks like, the task distribution is reasonably stable, and you can measure.

Knowledge in an LLM is stored diffusely across billions of weights, learned from seeing facts many times in varied contexts during pretraining. A fine-tune that mentions a fact a handful of times rarely creates reliably retrievable knowledge. The model may memorize the exact phrasing without generalizing to paraphrased questions.

Worse, research and practice both show fine-tuning on domain data can increase hallucination. This is because the model learns the confident tone and vocabulary of your domain without actually acquiring the underlying facts. So it answers fluently and wrongly.

The operational problems are just as serious:

• Updates: facts change; retraining for every price change or policy update is absurd.
• Deletion: you cannot reliably remove a fact from weights, which is a compliance problem for user data.
• Provenance: no citations, so users cannot verify answers.
• Access control: everyone who can query the model gets the knowledge; per-user permissions are impossible.

RAG solves all four: the index updates instantly, documents can be deleted, answers can cite sources, and retrieval can respect access control.

LoRA (Low-Rank Adaptation) fine-tunes a model without touching its original weights.

Why it took over:

• Memory: optimizer states and gradients exist only for the tiny adapter, not the billions of frozen weights. So an 8B model fine-tunes on a single modest GPU instead of a multi-GPU cluster.
• Artifact size: the adapter is tens of megabytes instead of tens of gigabytes, so you can store, version, and ship dozens of variants cheaply.
• Swappability: many adapters can share one loaded base model, enabling per-customer or per-task fine-tunes on shared serving infrastructure.
• No inference penalty: after training you can merge the adapter into the base weights, so the served model is exactly as fast as the original.
• Quality: for most product tasks (style, format, domain behavior), LoRA matches full fine-tuning closely. The low-rank constraint even acts as a regularizer that reduces catastrophic forgetting.

Hosted fine-tuning APIs generally run LoRA-style training under the hood for the same economics.