Vol. 04 · Prompting & Adaptation
Fine-Tuning Strategies
When to use fine-tuning, and when is RAG or prompting enough? LoRA, QLoRA, SFT, DPO, RLHF, distillation - broken down into focused cards. How to prepare data, how to evaluate the result, how not to waste the GPU.
Weekly knowledge desk
Fresh evidence
New signals, analysis and sources on this guide's subject from the last four reviewed weeks, newest first. The guide text itself is unchanged.
3 new items on this guide's subject
Items New Runtime published last week that bear on "Fine-Tuning Strategies".
- Fine-tuning GPT-OSS-20B for multilingual reasoning on Amazon SageMaker HyperPod post, Oct 22, 2026
- Fine-tuning a small model on expert trajectories can undo the gains from an evolved harness. analysis, Oct 22, 2026
- RLMF teaches small open models to state confidence that matches their sampling consistency, but the result is narrow and so far unreplicated analysis, Oct 24, 2026
3 new items on this guide's subject
Items New Runtime published last week that bear on "Fine-Tuning Strategies".
- Teams evaluating the pattern should define the target behavior first, separate training records from held-out evaluation data, test responses to multiple forms of guidance, monitor for reward explo... signal, Oct 14, 2026
- A Habr research write-up reports a controlled experiment on whether repeated fine-tuning lets a small signal, Oct 15, 2026
- A Habr research write-up reports a controlled experiment on whether repeated fine-tuning lets a small post, Oct 15, 2026
2 new items on this guide's subject
Items New Runtime published last week that bear on "Fine-Tuning Strategies".
3 new items on this guide's subject
Items New Runtime published last week that bear on "Fine-Tuning Strategies".
- Focusing on Post-Training post, Sep 28, 2026
- Focusing on Post-Training signal, Sep 28, 2026
- Fine-tune a search agent with multi-turn RL on Amazon SageMaker AI signal, Oct 2, 2026
The main question: should you fine-tune?
Fine-tuning solves different problems than RAG. They are often confused - and resources are wasted on the wrong things. The key question is: what exactly is not working in the current system?
RAG is about knowledge. Fine-tuning is about behavior and skills. If the problem is knowledge, RAG is cheaper, faster and updated without retraining.
Source-complete notesRAG wins when
text✓ Data is updated frequently
→ re-indexing is cheaper than retraining
✓ You need a link to the source (citation)
→ RAG gives attribution out of the box
✓ Large corpus of specific facts
→ the model does not remember facts well
✓ No GPU or training data
→ RAG works with API models
✓ Different clients with different knowledge bases
→ one index per client, one model
✓ Need transparency/audit
→ sources are always visibleFine-tuning is justified when the problem is not in knowledge, but in the way the model reasons, responds or behaves - and this cannot be fixed by prompts.
Source-complete notesFine-tuning is necessary when
sql✓ Need a specific style/tone consistently
→ “write as a lawyer for our company”
✓ The task requires domain reasoning
→ medical diagnostics, industrial calculations
✓ We need to remove the long few-shot from the prompt
→ saving tokens = reducing cost
✓ The problem cannot be solved by prompting at all
→ specific output format, rare language
✓ Need a small fast model (latency SLA)
→ GPT-4 distillation → 7B model
✓ Data is confidential and cannot be sent to the API
→ self-hosted fine-tuned modelThe best production systems combine both approaches: fine tuning teaches the model to reason correctly and respond in the right style, RAG provides up-to-date knowledge. These are not competitors - these are different layers.
Source-complete notesCombined architecture · Combo examples
sqlfine-tuned model:
✓ knows the company's output format
✓ understands domain terminology
✓ knows how to reason in the right style
✗ does not know specific facts of clients
+ RAG on top:
✓ current data
✓ specific facts from the database
✓ links to sources
→ the result is better than each one separatelyCombo examples
- medical assistant: SFT on clinical reasoning + RAG on patient history
- seller assistant: SFT on reporting format + RAG on WB/Ozon data
Supervised Fine-Tuning (SFT)
SFT (Supervised Fine-Tuning) - additional training of a pre-trained model on a dataset of pairs (input → output). The model can already do “everything” after pretraining; SFT does not add knowledge - it recalibrates the probability distribution to the desired answer format. This is supervised learning on top of an already trained model.
Source-complete notesWhen is SFT enough?
When is SFT enough?
- need a specific output format
- domain-specific task with examples
- remove long few-shot from prompt
- need 500–5000 high-quality examples
Special form of SFT: learning from a large set of varied instructions. This is what turns the base model into a chat model. FLAN, Alpaca, ShareGPT - datasets for instruction tuning.
Source-complete notesinstruction tuning data format
text{
"instruction": "Translate to English",
"input": "Hi, how are you?",
"output": "Hello, how are you?"
}
# thousands of such examples for different tasks
# → the model learns to follow any instruction
Key: variety of tasks is more important than volume
1000 different instructions > 10000 of the same typeWhen fine tuning, the model may “forget” the general abilities that were in the base model. It is especially dangerous with a small dataset and a large learning rate. The model does the new task well, but everything else is bad.
Source-complete notesHow to prevent
text✓ Low learning rate
1e-5 – 3e-5 for full fine-tuning
# don't break what already worked
✓ Small dataset → LoRA instead of full FT
# update minimum parameters
✓ Replay: mix with general-purpose data
# 10–20% of the original data in the dataset
✓ Early stopping by validation loss
# do not retrain to zero
✗ Many epochs on a small dataset
# → retraining, loss of general abilitiesLoRA & Parameter-Efficient Fine-Tuning
LoRA is the most popular method of effective fine tuning. Idea: do not update all the model weights (billions of parameters), but add small low-rank matrices on top of the key layers. Only they are updated - 0.1–1% of the parameters from the original model.
Change rank to see the trainable adapter grow.
- Base parameters
- 16,777,216
- Trainable adapter
- Trainable share
Source-complete notesParameter rank (r) - how to choose
Parameter rank (r) - how to choose
- r=4–8: simple tasks, format
- r=16–32: standard, most tasks
- r=64–128: complex domain reasoning
- r higher → more parameters, risk of overfitting
QLoRA = LoRA + base model quantization in 4-bit (NF4). The base model is loaded in 4-bit (frozen), LoRA adapters are trained in bf16. Allows fine-tuning 13B on 1× RTX 3090, 70B on 2× A100.
Source-complete notesMemory Requirements
textModel Full FT LoRA QLoRA
───────────────────── ─────────────────────
7B parameters 28 GB 14 GB 6 GB ← RTX 3090
13B parameters 52 GB 26 GB 10 GB ← RTX 4090
34B parameters 136 GB 68 GB 22 GB ← A100 40G
70B parameters 280 GB 140 GB 48 GB ← 2×A100
QLoRA quality loss vs LoRA: ~1-2% on most tasksLoRA is not the only PEFT method. Other approaches may be suitable for different problems and constraints. All implemented in the PEFT library from HuggingFace.
Source-complete notesAlternatives to LoRA
textDoRA (Weight-Decomposed LoRA)
separates magnitude and direction updates
→ slightly better than LoRA with the same rank
IA³ (Infused Adapter by Inhibiting and Amplifying)
scales activations, does not add matrices
→ even fewer parameters than LoRA
Prefix Tuning / Prompt Tuning
adds trainees "soft tokens" to the input
→ does not change the weight at all, few parameters
→ performs worse than LoRA on complex tasks
In practice: LoRA/QLoRA → default choiceLoRA adapters can be stored separately from the base model and loaded dynamically. One basic model + N adapters for N tasks - saving memory, fast switching. These are like plugins for the model.
Source-complete notesMulti-adapter serving
textbase_model = load("Llama-3.1-8B") # 1 time, 8GB
adapter_legal = load_lora("legal_v2") # 50MB
adapter_medical = load_lora("medical_v1") # 50MB
adapter_seller = load_lora("wb_seller") # 50MB
# at runtime on request:
model.set_adapter(route_to_adapter(query))
output = model.generate(query)
# LoRAX, vLLM, S-LoRA - servers with supportAlignment — RLHF, DPO, ORPO
RLHF is a three-step process that GPT-4, Claude, Gemini are trained on. This is not just “learning from feedback” - it is a complex pipeline with three separate models. It is RLHF that makes models useful and safe.
DPO (2023) is a mathematically equivalent solution to RLHF without a separate Reward Model and without RL. Key idea: it turns out that the RL problem can be reformulated as a supervised learning problem directly from preference data. It's elegant mathematics that simplifies everything.
Source-complete notesData for DPO
Data for DPO
- UltraFeedback, Anthropic HH-RLHF
- or generate: GPT-4 → chosen, bad model → rejected
ORPO (Odds Ratio Preference Optimization, 2024) combines SFT and DPO in one step. There is no need to do SFT first, then DPO - learning alignment occurs simultaneously with learning to follow instructions.
Source-complete notesPipeline comparison
sqlRLHF: pretraining → SFT → RM → PPO # 4 stages
DPO: pretraining → SFT → DPO # 3 stages
ORPO: pretraining → ORPO # 2 stages
ORPO Loss:
L = L_SFT + λ L_OR
where L_OR = log odds ratio(chosen vs rejected)
Practice: DPO - standard, ORPO - if there is no SFT checkpointInstead of human labelers, the LLM judge generates preference data. RLAIF (RL from AI Feedback, Anthropic) - Reward Model is trained on the estimates of a strong model. More scalable and cheaper than human markup.
Source-complete notesPipeline RLAIF · Applicable
python# Instead of people:
for prompt in dataset:
response_A = model.generate(prompt)
response_B = model.generate(prompt)
preference = judge_llm(prompt, A, B)
# "A is better because..."
pairs.append((prompt, A, B, preference))
# Next is the standard DPO on these pairs
train_dpo(model, pairs)Applicable
- no budget for markers
- you need a large dataset of preferences
Distillation - small model as big
Distillation is training a small model (student) to imitate a large one (teacher). Goal: get 80–90% teacher quality with 10x smaller inference size and cost. The basis for production optimization of LLM pipelines.
Source-complete notesApplicable
Applicable
- reduce cost by 10–50x
- latency < 100ms requires a small model
- self-hosted without API dependency
Not trying to distill “everything” from teacher is ineffective. Distill only a specific task: teacher generates synthetic data for a task, student learns only on it. A small specialized model beats a large general one.
Source-complete notesPractical pipeline
python# 1. Collect or generate task prompts
prompts = domain_prompts + synthetic_generated(N=5000)
#2. Teacher generates answers (expensive, one time)
dataset = [(p, gpt4(p)) for p in prompts]
#3. SFT of a small model on this data
student = finetune("Llama-3.1-8B", dataset, epochs=3)
#4. Eval: compare quality vs cost
# Result: quality ~85% teacher, cost 1/30Distill not only the answer, but also the chain of reasoning teacher. Student learns to reason like a large model. This is the basis of models like DeepSeek-R1-Distill - small models with strong reasoning.
Source-complete notesScheme
textteacher: o1 / DeepSeek-R1 / QwQ
→ generates: <think>...long argument...</think> response
dataset: (prompt, <think>reasoning</think> + answer)
student: Llama/Qwen 7–14B
→ SFT on full traces with reasoning
result: DeepSeek-R1-Distill-Qwen-7B
≈ 70% quality o1 at 1/100 costData is the bottleneck of all fine tuning
The main myth: “fine-tuning requires millions of examples.” The reality is different - a small, high-quality dataset is often better than a large, bad one. Quality >> quantity.
No data - LLM will generate synthetic ones. Self-Instruct, Evol-Instruct, Magpie - patterns for generating training data through strong models. Manual sample verification is required.
Source-complete notesSelf-Instruct pipeline
python# 1. Seed: 20-30 real quality examples
seed_examples = human_curated_examples
#2. LLM generates new instructions
new_instructions = GPT4(f"""
Here are examples of tasks: {seed_examples}
Generate 20 new similar but different problems.
""")
#3. LLM responds to generated instructions
dataset = [(instr, GPT4(instr)) for instr in new_instructions]
#4. Filtering: deduplication + quality filter
filtered = [x for x in dataset if quality_score(x) > 0.7]Bad data is the main reason why fine tuning fails. The model will learn exactly what is in the data—including errors, inconsistencies, and noise. Garbage in - garbage out literally works here.
Source-complete notesCommon data problems
textInconsistency
There are different correct answers to the same question
→ the model cannot learn the pattern
Duplication
one example 100 times → the model retrains it
→ deduplicate by embedding similarity
Leaked response prompt
output contains instruction parts
→ mask instruction correctly
Invalid chat template
<|user|> and <|assistant|> tokens are mixed up
→ the model learns the wrong roles
✓ Verification: manually review 100 random examplesData preparation takes 60–80% of fine tuning time. We need a reproducible pipeline with versioning, otherwise it is impossible to understand what produced the result.
Source-complete notesPipeline
textraw_data
→ collect logs, databases, synthetics, expert examples
→ clean remove noise, special characters, artifacts
→ deduplicate MinHash / embedding similarity
→ filter LLM-quality-score > threshold
→ model-specific format chat template
→ split train 90% / val 5% / test 5%
→ version git + DVC / HuggingFace Datasets
→ audit manual check of 100 examplesInfrastructure and tools
The ecosystem of tools is divided into levels: low-level (HF Transformers), high-level (Axolotl, LLaMA-Factory), managed (Modal, Together, OpenAI FT API). The choice comes down to control vs convenience.
Most hyperparameters are not critical - there are 5 parameters that determine 90% of the result. The rest is fine tuning after the basic launch works.
Source-complete notesStarting values
textlearning_rate: 2e-4 #LoRA; 1e-5 for full FT
lr_scheduler: cosine with warmup
warmup_ratio: 0.05 # 5% steps to warm up
epochs: 1–3 # rarely need more than 3
batch_size: per_device=2, grad_accum=8 # effective=16
max_seq_length: 2048 # per task
LoRA specific:
r: 16# rank
alpha: 32 # = 2×r usually
target_modules: ["q_proj","v_proj","k_proj","o_proj"]
dropout: 0.05Fine-tuning without eval is learning blindly. You need to monitor: train/val loss (overfitting?), target metric for holdout (real quality), general abilities (have they degraded?).
Source-complete notesChecklist ratings
textDuring training:
✓ is train_loss decreasing?
✓ val_loss is not growing? (if growing → overfitting)
✓ Is grad_norm stable? (spike → lr too high)
After training:
✓ target_metric on test set vs baseline
✓ general benchmarks have not fallen?
(MT-Bench, MMLU, HumanEval)
✓ human evaluation 50 examples
✓ compare vs prompted GPT-4 on the same taskFinal strategy map
Summary table for quick navigation through strategies.
Source-complete notestable
| Method | Solves | Data | GPU | Complexity |
|---|---|---|---|---|
| Prompting | Format and instructions | 0 | No | Low |
| RAG | Knowledge and facts | Index | No | Medium |
| SFT (LoRA) | Style and task behavior | 500–5k | 1×A100 | Medium |
| SFT (full) | Deep domain adaptation | 10k+ | 8×A100 | High |
| DPO | Behavior and safety | 500+ pairs | 1×A100 | Medium |
| Distillation | Cost and latency | 1k–20k | 1×A100 | Medium |
| RAG + SFT | Knowledge and style | Both | 1×A100 | High |
Before any fine tuning project, answer three questions. If there’s even one “no,” go back a step.
Source-complete notesChecklist before start
text1. Have you exhausted your prompting?
Have you tried few-shot, CoT, persona, chain?
No → prompting first, it's free
2. Do you have data and metrics?
Minimum 200 quality examples?
A clear metric by which to measure improvement?
No → first collect data and define a metric
3. Is the problem in behavior, not knowledge?
If you add the correct data to the prompt → does everything work?
Yes → use RAG, not fine tuning
All three yes? Fine-tune.
Start with LoRA on 7-8B models.
Compare with prompted GPT-4 on your task.No dead end
Keep moving through the map.
Continue in sequence, switch to a related guide, or return to the seven-track learning map.