Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →evo-hq/finetuning
This skill should be used when picking or diagnosing a training move (SFT, LoRA, DPO/KTO/ORPO, RFT, GRPO/PPO/RLOO, RLHF), or when the user mentions fine-tuning, post-training, training recipe, reward design, or weight updates. Decision tree by reward shape, smoke-run gate, three failure diagnostics, five false-progress patterns. Provider recipes and I/O contract in references/.
Passed 21 of 21 test cases with the skill, and 12 of 21 without it.
and 14 more in the full report
10 fixed13 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
When running multi-experiment trees, context window resets can cause loss of active state details like dataset URLs, techniques, and hyperparameter choices. Where should these metadata parameters be logged within the experiment worktree?
| Checked | Without skill | With skill |
|---|---|---|
| Instructs writing dataset URL, technique choice, constraints, and hyperparameters to methodlog.md | Missed | Passed |
The instructions your model reads when the skill loads.
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.
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 |
"SFT-then-RL" is not a law. For a competent base model on a verifiable benchmark, RL-from-base often beats SFT-then-RL end-to-end.
The decision tree above is the structural prior. The empirical answer for this model on this benchmark usually has a recent paper, blog, or HF Space recipe behind it -- and what beats baseline on a 4B base model in 2026 is not what the agent's pre-training data captures. Before picking the technique for exp_0001 (the first experiment after baseline), invoke evo:ideator with a literature brief:
Task(
subagent_type="evo:ideator",
prompt="brief=literature\n"
"model_family=<e.g. Qwen3-4B-Base, Llama-3.1-8B-Base>\n"
"benchmark=<name + URL/paper if known>\n"
"objective=<one line: what beats baseline looks like>\n"
"constraints=<budget, data sources allowed, gated models forbidden, etc>"
)
The ideator returns ranked proposals with references (arXiv, HF Hub, GitHub, blogs). Read them before picking from the reward-shape table. A paper showing GRPO-from-base works on <model_family> for a similar verifiable benchmark beats applying the table cold.
Run this once before exp_0001, and again whenever the optimize loop hits a plateau (the "stuck across distinct techniques" diagnostic below). Not every subsequent experiment needs a literature pass -- the table + diagnostics carry the rest.
Run the full pipeline on ~10 examples for ~1 minute. Must produce: a checkpoint the benchmark can load AND a non-zero eval on a held-out item. If not, the recipe is broken — fix it, don't scale it. dtype mismatch, tokenizer/template drift, OOM at this batch size, empty artifacts dir despite falling loss — all surface on 10 examples. Running longer doesn't surface them differently, just more expensively.
test cases passed, vs 12 / 21 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.