The Practical Recipe

Lesson 4 of 4 in Fine-Tuning: Full, LoRA, QLoRA.

The recipe starts before any training: build the eval first. A fixed, held-out test set — real inputs from your traffic, graded against what good looks like — frozen before the first run and never trained on. Without it, “did fine-tuning help?” has no answer; you will be comparing vibes against vibes, and every subsequent iteration compounds the blindness. (How to build defensible evals — graders, contamination, Benchmark hygiene — is the Evaluation domain’s territory; here, the recipe just demands that something fixed exists before the money is spent.)

Then comes data, and the rule is curation over volume. The post-training domain already taught the LIMA lesson — a small set of carefully curated demonstrations can beat a large sloppy one — and it applies with full force here: the model will learn your dataset’s actual patterns, including the inconsistent formatting, the wrong answers, and the labeling disagreements you did not notice. A thousand examples someone has read beat fifty thousand nobody has. Reading data is the least glamorous, highest-leverage hour in the whole recipe — and a model can help you spend it well:

Spot-check a training example before it enters the set
You are auditing one candidate example for a fine-tuning dataset.

The fine-tune’s target behavior: {{TARGET_BEHAVIOR}}
The style/format rules the outputs must follow: {{STYLE_RULES}}

Candidate example:
INPUT: {{EXAMPLE_INPUT}}
OUTPUT: {{EXAMPLE_OUTPUT}}

Grade the example:
1. CORRECT — is the output factually and logically right for this input?
2. ON-TARGET — does the output demonstrate the target behavior, not something adjacent?
3. CONSISTENT — does it follow every style/format rule, exactly?
4. CLEAN — is it free of PII, internal URLs, boilerplate, or artifacts of how it was collected?

Verdict: KEEP / FIX (say precisely what to change) / DROP (say why).
Be strict: an example that is 90% right teaches the 10% wrong part too.

Run this over a random sample, not the whole set — the goal is to estimate quality and sharpen your labeling guidelines before training, not to outsource curation. Disagreements between graders are a finding: fix the guidelines, then the data.

With evals and data in hand, the hyperparameters that matter are few. Epochs: a small number of passes over the data — fine-tuning datasets are tiny by pre-training standards, and each extra pass pushes toward memorization. Learning rate: far smaller than pre-training’s — too high and you bulldoze the base model’s abilities; too low and nothing changes. (For LoRA, add the rank r and which layers get adapters.) Treat published defaults as starting points and let the eval set arbitrate.

Watch for overfitting, which in fine-tuning has recognizable faces: training Loss still falling while held-out eval quality degrades; verbatim regurgitation of training examples; style so locked-in that the model imposes it where it should not; and regression on general ability — the model gets better at your task and quietly worse at everything else (the catastrophic forgetting face). Every one of these is caught by the eval set you built first, and invisible without it.

Should you fine-tune?

Interactive decision tree — outcomes:

  • Retrieval, not weights

    Facts belong in retrieved context the model can quote — updatable by re-indexing, not retraining. Revisit fine-tuning only for how the model uses what it retrieves (format, citation style), never for the facts themselves.

  • Prompt first

    Prompting is cheaper, reversible in minutes, and its failures teach you what a fine-tune would need to fix. Fine-tuning before exhausting prompts buys risk with money.

  • Fine-tuning fits poorly

    Weights encode consistent patterns. Case-by-case behavior is better served by per-request context — instructions, examples, retrieved evidence — than by a single baked-in disposition.

  • Fine-tune — with the recipe

    You have the right problem and the right assets. Default to LoRA (or QLoRA if memory-bound), start from published hyperparameter defaults, and let the eval set judge every run against the un-tuned baseline.

  • Not yet — build the eval and the data first

    Training without a fixed eval set is spending without a scoreboard, and uncurated data teaches uncurated behavior. Build both; the fine-tune will still be there next month.

Tool: Prompt vs RAG vs Fine-tune — The Adaptation Advisor walks this same logic interactively across all the levers — prompt, retrieval, weights — with your scenario’s specifics.

The last recipe step is deciding how the Adapter reaches production, and there are two honest patterns. Merge folds BA into the base weights offline: you serve a plain model, zero added latency, no adapter machinery — the right call when one behavior serves everyone. Runtime attach keeps the base and adapters separate: one copy of the base in GPU memory, adapters loaded per request or per tenant — the right call when many variants must share hardware. Modern serving engines support this multi-adapter pattern natively, batching requests for different adapters through one base model; the mechanics of batching itself are the serving-engines module. The trade: merging gives simplicity and speed for one behavior; attaching gives fleet economics for many. What you should not do is let this choice happen by default — per-tenant adapters that were quietly merged into per-tenant full copies forfeit the economics that justified LoRA in the first place.

In production

Managed fine-tuning on the big clouds is the same mechanics under the hood — SFT with full or (Q)LoRA-style parameter-efficient training. The differences that matter are mechanism-level: what artifact you get back, and whether you can leave with it.

AWS

Amazon Bedrock’s model customization takes your example pairs, runs a managed training job against a hosted foundation model, and hands back a custom model you invoke through the same API — the tuned weights for proprietary models stay inside the platform, so the artifact is effectively an endpoint. The complementary mechanism runs the other direction: models you fine-tune yourself (for example QLoRA on open weights, on your own instances or SageMaker) can be imported and served — that path leaves you owning a portable artifact.

Azure

Azure AI Foundry fine-tuning follows the upload-train-deploy shape: training data in a JSONL conversation format, a managed job that for hosted models runs parameter-efficient (LoRA-style) tuning, and the result deployed as a model endpoint in your resource. For the proprietary models the weights never leave the service — portability is the endpoint and the training data you still hold, so keeping that data versioned outside the platform is what keeps you mobile.

Google Cloud

Vertex AI’s supervised tuning for its hosted models is likewise adapter-based parameter-efficient training under the hood, returning a tuned endpoint rather than downloadable weights. For open-weight models, the same platform’s training infrastructure lets you run (Q)LoRA jobs where the adapter file is yours — the portability line runs between hosted-proprietary (endpoint) and open-weight (artifact), not between clouds.

Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.