Finetuning

Reach for this when you're choosing between SFT, LoRA, DPO, GRPO, or any other post-training method, or when debugging why your training run isn't moving the needle. It starts with a decision tree keyed to reward shape: verifiable benchmarks get RL, preference pairs get DPO, demonstrations get SFT. The diagnostics are practical: stuck at zero on a verifiable task means you picked the wrong technique class, not that you need to tune hyperparameters. It enforces smoke runs on ten examples before you burn GPU budget, builds mid-training eval and early stopping directly into scripts, and caps retries at one for training-scale experiments. The literature brief pattern via evo:ideator is smart, most teams skip that step and waste time rediscovering what already works for their model family.

GitHub stars: 1.1K
last updated: Jun 11, 2026

View on GitHub

Install

$ npx -y skills add evo-hq/evo --skill finetuning --agent claude-code

Installs into .claude/skills of the current project.

Files

Finetuning

Priors, not rules. Only firm guardrails: held-out eval you never train on, no leakage, trust evo's recorded numbers over the run's self-report. Override anything else against the gate.

Pick the technique by reward shape

Decide on the reward first, technique second. Choosing the comfortable technique over the matching one is the most common failure.

Reward shape	Technique
Verifiable (exact match, unit tests, parser-decidable)	RL (GRPO / RLOO / PPO) — reward includes format, so the model learns to emit verifier-acceptable shape
Preference pairs (chosen vs rejected)	DPO / KTO / ORPO — cheaper than full RL, no rollouts
Demonstrations only (curated traces, chat data)	SFT — install format/tone/capability the base lacks
Have a scorer + want SFT stability	RFT — sample, filter by reward, SFT on survivors