How to Fine-Tune an LLM: LoRA vs Full Fine-Tuning vs RAG
When to fine-tune a large language model, how LoRA and QLoRA compare with full fine-tuning, how much data you need, and how to evaluate the result.
Fine-tune an LLM when you need consistent behaviour — a format, tone, domain vocabulary or a narrow task done cheaply by a smaller model. Use RAG when you need up-to-date or private facts. For most teams, parameter-efficient methods such as LoRA or QLoRA on a few thousand high-quality examples give most of the benefit at a fraction of the cost of full fine-tuning.
When does fine-tuning make sense?
Fine-tuning changes a model's weights so it behaves differently by default. It is a good fit when:
Fine-tuning vs RAG: which do you need?
Fine-tuning teaches behaviour; RAG supplies knowledge. If the model gives wrong facts because it has not seen your documents, fine-tuning is the wrong tool — the facts will go stale and cannot be cited. If the model knows the facts but answers in the wrong shape or tone, fine-tuning helps.
Before either, try better prompting and a few examples in the prompt. If that closes the gap, you may not need to train anything.
LoRA, QLoRA and full fine-tuning compared
Full fine-tuning updates every weight. It can achieve the deepest adaptation but needs substantial GPU memory, careful hyperparameters and produces a full copy of the model per variant.
LoRA (low-rank adaptation) freezes the base model and trains small adapter matrices. Training needs far less memory, adapters are small files that can be swapped at serving time, and quality is close to full fine-tuning for most tasks. QLoRA goes further by loading the base model in 4-bit precision, making it practical to tune larger models on a single GPU.
After supervised fine-tuning, preference methods such as DPO or ORPO can align the model with what reviewers prefer, and distillation can transfer a large model's behaviour into a smaller one.
How much training data do you need?
Quality matters far more than quantity. A few hundred to a few thousand clean, representative, correctly labelled examples often outperform a much larger noisy set. Each example should look like the real inputs the model will receive and the exact outputs you want.
When real examples are scarce, synthetic data generation can help: generate candidate instruction–response pairs from your documents, filter them with automated scoring, and have domain experts review a sample. Always remove personal data and deduplicate before training.
How do you evaluate a fine-tuned model?
Freeze a held-out test set before training starts, drawn from real cases and never used for training. Compare the tuned model against the base model with the best prompt you could write — that is the bar fine-tuning must beat.
Measure task accuracy, format validity, refusal behaviour and regressions on general capability. Gate every new version on this evaluation suite, exactly as you would gate a software release on tests.
What does a practical fine-tuning pipeline look like?
A repeatable pipeline turns fine-tuning from an experiment into an engineering process:
- Outputs must follow a strict structure every time, such as JSON for downstream systems.
- The domain has specialised terminology or style the base model handles poorly.
- A long, expensive prompt can be replaced by a smaller model that has learned the task.
- Latency or cost requires a small model to match a large model on one narrow task.
- You need a model to run privately on your own infrastructure.
- Curate and version the dataset (JSONL or ChatML), with PII removed.
- Train with a known recipe — for example Hugging Face TRL, Axolotl or Unsloth with LoRA adapters.
- Evaluate on the frozen test set and record results per version.
- Optionally align with preference data, then distil if a smaller model is the goal.
- Serve with an inference engine such as vLLM, and monitor quality in production.
- Our fine-tuning and data generation services run this pipeline for domain models — see the service pages for details.
