Reference · How-to · ~12 min
How to train a LoRA adapter
Last updated
Teach style and format without retraining the full base model — then prove it beats prompting/RAG on your golden tasks.
Teach style and format without retraining the full base model — then prove it beats prompting/RAG on your golden tasks.
#Prerequisites
- Base model you are allowed to fine-tune
- 200–500 high-quality input/output pairs (more if the task is broad)
- A held-out eval set you will not train on
- GPU or hosted fine-tune job with version pins
#Steps
1. **Curate pairs** that show the exact behavior you want (JSON shape, tone, refusal style). Drop duplicates and contradictory labels.
2. **Hold out ~10%** as validation; keep a separate golden-task list for product metrics.
3. **Train LoRA** on a frozen base; log learning rate, rank, steps, and base model revision.
4. **Eval** against a prompt-only baseline and a RAG baseline on the same golden tasks.
5. **Pin** adapter + base version in deploy config; store a rollback adapter ID.
6. **Canary** a small % of traffic; watch format fail rate and cost.
#Expected output
A versioned adapter artifact, an eval report (win/lose vs baselines), and a deploy note that names base model + adapter commit.
#Failure notes
- Overfitting cute demos that fail on real tickets
- Training for facts that should be retrieved (use RAG instead)
- Mismatched chat templates between train and serve
#Mini example
Task: always answer support macros as:
{"intent": "...", "reply": "...", "escalate": true|false}
Eval: 50 tickets scored for schema validity + policy match
Ship only if schema validity ≥ 98% and policy match ≥ prompt baseline