From Imitation to Preferences: Why Ranking Beats Copying
By the end of this lesson you will be able to say exactly what supervised fine-tuning cannot learn and why a comparison fixes it; describe the classical preference pipeline as four named stages with a reward model in the middle; explain what the KL term is holding the model to and what happens at both extremes; recognise the three dataset shapes preference methods consume; and place PPO, DPO and GRPO on one family tree so that a paper’s method section stops being a wall of symbols.
Part 3 told this story once, at the level of “what happened and in what order”. This lesson is the same story with the mechanism visible, because from here on you are the one setting the hyperparameters.
Where imitation stops
Section titled “Where imitation stops”Supervised fine-tuning computes one thing: the negative log-likelihood of the tokens you supplied, given the prompt. Every example is a target to be reproduced. The training signal never contains the sentence “this answer is better than that one”, because only one answer was ever present.
Three consequences follow, and all three show up in real fine-tunes.
It cannot exceed its data. If the demonstrations hedge, the fine-tune hedges. If they are merely adequate, the fine-tune is merely adequate. There is no gradient pushing towards anything better than what you wrote down, because nothing in the loss represents “better”.
It cannot learn what to avoid. A demonstration says “do this”. It never says “and not that”. A model that habitually pads its answers with a closing offer of further help will keep doing so after a fine-tune on examples that simply lack the padding, because absence is a weak signal compared with presence.
The data is expensive in the one place it matters. Writing an excellent answer to a hard question needs somebody who could have answered it. Collecting a thousand of those is a project. This is not a machine-learning limitation at all; it is a labour cost, and it is the one that preference methods attack.
What a ranking knows that a demonstration does not
Section titled “What a ranking knows that a demonstration does not”Show two answers to the same prompt and ask which is better. The answer is one bit, it takes a few seconds, and the person giving it does not have to be able to write either answer. That is the whole economic argument, and Part 3 quoted the InstructGPT paper making it at scale: the authors collected demonstrations first, then “a dataset of rankings of model outputs”, and used the second to push the model further than the first could.
The technical argument is different and more interesting. A comparison is a statement about the model’s own output distribution. Both answers came from the model; one of them is a direction it already goes in and should go in more, the other a direction it should go in less. A demonstration is a point you supplied from outside, which the model may or may not be able to reach. A preference pair is a gradient defined on ground the model already occupies.
That is why preference tuning tends to move behaviour that fine-tuning could not budge: verbosity, hedging, register, the shape of a refusal, the habit of answering the question that was asked. All of them are differences between two plausible outputs rather than the difference between an output and an ideal.
The three shapes preference data comes in
Section titled “The three shapes preference data comes in”TRL’s dataset documentation names the shapes, and they matter because each trainer accepts a
different one. A preference dataset carries a prompt with a chosen and a rejected
completion. An unpaired preference dataset carries a prompt, a single completion and a
boolean label saying whether it was desirable. A prompt-only dataset carries the prompt and
nothing else, because the completions will be generated during training.
Those three shapes are the fault line running through the rest of this part. Paired preferences feed DPO. Unpaired ones feed KTO. Prompt-only feeds everything that samples from the model as it trains, which is PPO, GRPO and the online methods. If you find yourself unable to run an algorithm on a dataset, this is almost always why.
The classical pipeline
Section titled “The classical pipeline”Reinforcement learning from human feedback is four stages, and naming them is most of understanding it.
Reinforcement learning from human feedback, stage by stage
- 1. Supervised fine-tuningTrain on demonstrations. Produces the policy that everything after this starts from, and the reference the KL term is measured against.
- 2. Collect comparisonsSample two or more completions per prompt from that policy, and have people rank them. The completions come from the model so that the labels describe the model.
- 3. Train a reward modelA model that reads a prompt and a completion and returns one number, fitted so that the preferred completion in each pair scores higher. Usually the policy with its output head replaced.
- 4. Optimise the policy against itSample completions, score them with the reward model, and update the policy towards what scored well - with a KL penalty holding it near the stage-1 model.
The reward model is a model, with all that implies
Section titled “The reward model is a model, with all that implies”Stage 3 is the part people skip over, and it is where most of the trouble lives. A reward model is trained on comparisons, usually under the Bradley-Terry assumption that the probability of preferring one completion over another is a logistic function of the difference between their scores. Fit that on your pairs and you have a function from text to a number.
It is a neural network trained on a finite sample, so it is wrong in places, and the places it is wrong are exactly where an optimiser will go. This has a formal name. Skalse and colleagues give “the first formal definition of reward hacking, a phenomenon where optimizing an imperfect proxy reward function leads to poor performance according to the true reward function”, and their analysis is not encouraging: they define an “unhackable” proxy as one where “increasing the expected proxy return can never decrease the expected true return”, and find that for all stochastic policies this holds only in degenerate cases, concluding that “the linearity of reward (in state-action visit counts) makes unhackability a very strong condition”.
Read plainly: a learned reward model that you optimise hard enough will be exploited. Not through bad luck, but because the optimiser is doing its job and the proxy is not the thing you wanted.
PPO, in one paragraph
Section titled “PPO, in one paragraph”Stage 4 is usually proximal policy optimisation. Its paper describes “a new family of policy gradient methods for reinforcement learning, which alternate between sampling data through interaction with the environment, and optimizing a ‘surrogate’ objective function using stochastic gradient ascent”, and the reason it displaced what came before is stated just as plainly: “whereas standard policy gradient methods perform one gradient update per data sample, we propose a novel objective function that enables multiple epochs of minibatch updates”.
Two words in that quotation carry the practical weight. Alternate means the loop is sample-then-update, so generation happens inside training and dominates the wall clock. Surrogate means the objective is not the reward directly but a clipped ratio between the new policy and the one that did the sampling, which is what makes several updates on the same batch safe.
For language models this costs four models in memory at once: the policy being trained, a frozen reference, the reward model, and a value network (the critic) that estimates how good a partial completion is. That count is the single biggest reason PPO is rare on one machine, and it is the count GRPO attacks.
The leash: what the KL term holds
Section titled “The leash: what the KL term holds”Every method in this part carries a term that measures how far the policy has moved from a frozen reference model, and penalises it. It is worth being precise about why.
Optimising a score with no constraint finds the maximum of that score, which for any learned or hand-written reward is some degenerate output: a wall of the reward model’s favourite tokens, or an empty answer that trivially satisfies a format check. The reference model is a statement of “stay recognisably like the thing that was already useful”. The KL coefficient, usually written beta, is how tightly.
Both extremes fail in a way you can recognise in a log:
- Too tight (large beta, or a KL penalty that dominates): reward barely moves, the completions stay almost identical to the reference, and you have spent an afternoon of GPU time on nothing.
- Too loose (small or zero beta): reward climbs beautifully and the completions degrade. Repetition, drifting language, answers that satisfy the letter of the reward and nothing else. The reward curve is not evidence that this is not happening, which is why the labs in this part make you look at samples.
The family tree
Section titled “The family tree”Everything after the classical pipeline is an argument about which of the four stages you can delete.
| Method | Keeps | Deletes | Data it needs | Cost on one machine |
|---|---|---|---|---|
| PPO | All four stages | Nothing | Prompt-only, plus a trained reward model | Four models resident; generation inside the loop |
| DPO | Stages 1 and 2 | The reward model and the whole reinforcement-learning loop | Paired preferences, offline | One trainable model and a reference; no sampling during training |
| GRPO | Stages 1, 2 and 4 | The critic network, and the reward model where the reward is a program | Prompt-only, plus a reward function | Policy, optional reference, and a rollout engine |
DPO’s route is the one Part 3 described: its authors introduce “a new parameterization of the reward model in RLHF that enables extraction of the corresponding optimal policy in closed form, allowing us to solve the standard RLHF problem with only a simple classification loss”. The reward model does not vanish so much as get folded into the policy, which is what the paper’s subtitle means by “your language model is secretly a reward model”. The next lesson makes that concrete.
GRPO’s route is different. Its paper introduces it as “a variant of Proximal Policy Optimization (PPO), that enhances mathematical reasoning abilities while concurrently optimizing the memory usage of PPO”. It keeps the sampling loop and removes the critic, by scoring a group of completions to the same prompt and using their spread as the baseline the critic used to supply. Where the reward is a program rather than a model, the reward model goes too. That is two of the four networks gone, and it is why a reinforcement-learning run fits on a desk.
What preference tuning changes, and what it does not
Section titled “What preference tuning changes, and what it does not”It moves the things a comparison can express. Tone, length, the decision to answer directly rather than restate the question, the shape of a refusal, which of two correct answers gets produced. On a narrow style you can see the change after a few hundred pairs.
It does not install knowledge, for the same reason supervised fine-tuning does not: a comparison between two answers says which you preferred, not what is true. If both answers are confidently wrong, the pair teaches the model which flavour of wrong you like.
And it has a documented tendency to make answers longer, because longer answers are frequently preferred by both people and judges. That tendency is real enough that two of the methods in the next lesson exist mainly to counter it, and the DPO lab records mean answer length before and after for exactly this reason.
A preference label needs a reason and a comparison unit
Section titled “A preference label needs a reason and a comparison unit”Suppose two answers are both factually correct, but one is concise and the other explains a useful caveat. Which is preferred depends on the task and reviewer policy. Label the property being judged and permit a tie or exclusion when the rubric does not distinguish the pair.
Keep the prompt identical within a pair. If the chosen answer had access to a different document or tool result, the pair confounds preference with evidence availability. Inspect length and formatting distributions too: a model can learn “longer is preferred” when reviewers intended “more complete is preferred”.
Split by the underlying prompt or source task before creating alternative answers. A held-out paraphrase of a training prompt may not establish transfer. Evaluate the resulting model on new prompts with both the preference rubric and independent correctness checks. Preference optimisation shifts relative behaviour; it does not make every chosen example objectively true or resolve inconsistent values among reviewers. The dataset’s comparison policy is part of the model’s intended behaviour.
Supervised fine-tuning can only reproduce its examples, cannot express “not that”, and needs expensive labour precisely where quality matters. A preference pair is cheaper to collect and carries a comparison between two outputs the model already produces. The classical pipeline turns those comparisons into a reward model and optimises the policy against it with PPO, holding it near the supervised model with a KL penalty; the reward model is a fitted network, so optimising it hard finds its errors, which reward hacking has a formal definition for. DPO deletes the reward model and the loop; GRPO keeps the loop, deletes the critic by scoring groups, and deletes the reward model wherever a program can compute the reward. The dataset shape - paired, unpaired or prompt-only - decides which of them you can run at all.
Check your understanding
Sources for this lesson
7 verified · checked 2026-09-09
- 01Training language models to follow instructions with human feedback (Ouyang et al., arXiv:2203.02155)§ Abstractarxiv.org/abs/2203.021552026-09-09
- 02Proximal Policy Optimization Algorithms (Schulman et al., arXiv:1707.06347)§ Abstractarxiv.org/abs/1707.063472026-09-09
- 03Direct Preference Optimization: Your Language Model is Secretly a Reward Model (Rafailov et al., arXiv:2305.18290)§ Abstractarxiv.org/abs/2305.182902026-09-09
- 04DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models (Shao et al., arXiv:2402.03300)§ Abstractarxiv.org/abs/2402.033002026-09-09
- 05Defining and Characterizing Reward Hacking (Skalse et al., arXiv:2209.13085)§ Abstractarxiv.org/abs/2209.130852026-09-09
- 06TRL documentation — Dataset formats and types§ Preference; Unpaired preference; Prompt-only; Which dataset type to usehuggingface.co/docs/trl/dataset_formats2026-09-09
- 07TRL documentation — DPO Trainer§ Looking deeper into the DPO method; Logged metricshuggingface.co/docs/trl/dpo_trainer2026-09-09
Every technical claim on this page was checked against the official documentation of the tool, vendor or model publisher on the date shown, at the version pinned for the course. Where the course disagrees with folklore, the source is how you can tell which one to trust.