II · THE IDEA · ARTIFICIAL INTELLIGENCE
Crowdsourcing High-Quality Human Feedback
▶ Listen · narrated
A language model only learns what humans prefer if someone first collects those preferences, cleans them, and turns ranked outputs into something an optimiser can trust.
At a glance
- Core unit
- A prompt with two or more model completions humans can rank
- InstructGPT path
- Rankings train a reward model; PPO then optimises the policy
- DPO path
- Same pairwise preferences enter a direct policy loss
- Label workforce
- Screened contractors, not ad-hoc crowd clicks alone
- Aggregation
- Full rankings reduced to pairwise preferred–dispreferred pairs
Think of tasting two plates of food and saying which you prefer, not giving each a score out of ten. That is the basic unit of this work: for one question (the prompt), the model cooks several answers, and a person ranks them.
Those rankings are chopped into pairs—answer A beat answer B. Many such pairs teach a computer what “better” looks like. One approach builds a separate scoring machine from the pairs, then pushes the model to score highly. Another approach, DPO, uses the pairs to nudge the model straight away, without building that separate scorer.
The hard part is not the maths; it is the people and the rules. Who ranks, what instructions they follow, and how careless votes are removed decide whether the model learns a clear idea of helpful and safe behaviour or only a muddle of opinions.
InstructGPT-style preference collection: sample K completions per prompt from a supervised policy; collect a full or partial ranking from screened labelers under written criteria; expand rankings into pairwise (preferred, dispreferred) comparisons. Fit a reward model rφ by maximising a Bradley–Terry-style likelihood so that rφ(x, y_w) > rφ(x, y_l). Optimise the policy with PPO against rφ, typically with a KL penalty to a reference model to limit drift.
DPO: begin from the same class of pairwise dataset D = {(x, y_w, y_l)}. Rather than fitting rφ and running RL, reparameterise the optimal policy so that preference likelihood becomes a binary classification loss on the policy πθ relative to a frozen reference π_ref. The update increases log-probability mass on y_w and decreases it on y_l, scaled by how badly the current implicit reward orders the pair.
Shared methodology and failure modes: label noise, ambiguous rubrics when objectives conflict, distribution shift between demonstration prompts and ranking prompts, and over-narrow labeler pools. Filtering near-duplicates and uninformative ties improves pair quality. Neither path removes the need for coherent human rankings; DPO only removes the explicit reward-model and PPO stages after aggregation.
Look closer
The comparison, not the score
Both pipelines begin from relative judgments. Labelers see several completions for one prompt and put them in order, or mark which of a pair is better. Absolute quality scores are avoided; the training signal is “A beats B on this prompt.” That choice keeps the task tractable for humans and matches the Bradley–Terry-style preference models that later stages assume.
Who is allowed to label
High-quality preference data is not gathered by opening an unfiltered public form. The InstructGPT work used hired contractors, screening, and written guidelines so that rankings reflected a coherent notion of helpful, honest, harmless behaviour rather than whatever a random clicker rewarded. Agreement between labelers, and between labelers and researchers, is imperfect; the methodology treats that noise as something to measure and manage, not something that disappears at scale.
One dataset, two optimisation stories
Once pairwise preferred and dispreferred completions exist, they can feed a separate reward model that a reinforcement-learning stage maximises, as in InstructGPT, or enter a classification-style objective that updates the policy directly, as in DPO. The collection and filtering problem is largely shared; the papers diverge on what happens after the preferences are clean enough to trust.
The story
Instruction-following models are only as aligned as the human judgments used to steer them. The practical problem is not merely “get some feedback,” but how to collect preference data that is consistent enough, large enough, and clean enough to train on—and how to aggregate noisy rankings into a signal an optimiser will not overfit or game.
The InstructGPT pipeline makes the data stages explicit. First, labelers write demonstration outputs for prompts; those demonstrations support supervised fine-tuning. Next, for a broader set of prompts, the model produces several candidate completions. Labelers rank those candidates. Rankings are decomposed into pairwise comparisons: whenever completion A is placed above completion B, the pair (prompt, A preferred, B dispreferred) becomes a training example for a reward model. That reward model is then the objective a policy optimises with reinforcement learning, using PPO. Every later stage inherits the strengths and defects of those ranked comparisons.
Collecting the rankings is a methodology problem before it is a modelling problem. Prompts must cover the behaviours one cares about. Completions must be diverse enough that rankings are informative, not ties between near-duplicates. Labelers need instructions that define what “better” means when helpfulness, truthfulness, and harmlessness pull in different directions. Screening and ongoing quality checks matter because a small fraction of careless or adversarial rankings can distort the reward model. Researchers also measure how often labelers agree with one another and with the research team; disagreement is expected, and the pipeline is designed around relative orderings rather than perfect consensus.
Aggregation is deliberately simple at the interface to learning. A full ranking of K outputs yields multiple pairwise preferred–dispreferred pairs. Those pairs train a reward model under a preference likelihood (in the spirit of Bradley–Terry): the model learns to assign higher scalar reward to the preferred completion than to the dispreferred one for the same prompt. Filtering can remove obviously broken outputs, near-duplicates, or comparisons where labelers could not decide. What remains is still human and noisy, but it is structured enough to supervise a reward head.
Direct Preference Optimization starts from essentially the same kind of pairwise data and asks a different question: if the goal is a policy that prefers A to B, must one train an explicit reward model and run PPO at all? DPO shows that the constrained reward-maximisation problem can be rearranged so the policy itself is updated with a classification-style loss on preferred versus dispreferred completions, using a reference model as an anchor. The collection problem does not vanish—someone must still produce reliable (prompt, chosen, rejected) triples—but the engineering path after aggregation shortens.
At scale, the scarce resource is not raw clicks but coherent preference judgments. Labeler selection, written criteria, ranking interfaces rather than absolute scores, and pairwise aggregation are the methodological spine shared by both lines of work. The algorithms differ; the demand for carefully gathered human rankings does not.
Why it mattered then
When InstructGPT was introduced, large language models were already fluent but unreliable at following user intent. Supervised demonstrations helped, yet they were expensive to write at volume and did not directly express trade-offs between competing answers. Ranked comparisons offered a way to harvest many judgments per prompt and to train a reward model that could generalise preference beyond the exact demonstration set. That mattered in the moment because it turned “alignment” into an operational data pipeline: hire and screen labelers, issue guidelines, collect rankings, fit a reward model, optimise with PPO. DPO later mattered for a complementary reason: teams already sitting on preference datasets needed a simpler training recipe that avoided the instability and implementation cost of RL while still using the same human comparisons. In both cases, the bottleneck that defined the moment was methodological—how to get preference data good enough that the subsequent optimiser was worth running.
Why it matters now
Open-weight fine-tuning has made preference optimisation widely accessible, but accessibility does not invent label quality. Anyone running DPO or a reward-model-plus-RL stack still depends on how prompts were chosen, how completions were sampled, who ranked them, and how ties, spam, and conflicting criteria were handled. Crowdsourcing without screening tends to reward superficial fluency; small, well-instructed label pools produce narrower but more coherent signals. As models are adapted for products, domains, and languages, the same design choices—pairwise rather than absolute scores, clear rubrics, aggregation into chosen/rejected pairs—decide whether the training signal reflects the intended users or only the loudest annotators. The papers remain relevant because they separate what must be true of the data from what can vary in the optimiser.
The surprising detail
The same ranked comparisons can train either an explicit reward model for PPO or a policy updated directly by DPO. The human methodology—screened labelers, multi-output rankings, decomposition into pairs—does more lasting work than the choice of which loss consumes the pairs. Preference quality is upstream of both algorithms; neither paper claims that scale alone repairs careless labeling.
What is disputed
Labeler agreement with researchers and with other labelers is imperfect in the reported InstructGPT work; preference data is inherently noisy. Neither paper claims a single best workforce size or ranking interface for every domain. DPO assumes preference data of the same pairwise form, but real-world gains still depend on how carefully those pairs were gathered and filtered.
Remember this
Preference learning is only as sound as the ranked comparisons you collect, who you allow to rank, and how you turn those rankings into preferred–dispreferred pairs.
Test yourself
You have full rankings of four completions per prompt from screened labelers. You plan to try both a reward-model-plus-PPO pipeline and DPO. What shared aggregation step should you perform once, and what does each method do with the result?
Decompose each ranking into pairwise preferred–dispreferred examples for the same prompt (every higher-ranked completion versus each lower-ranked one, or a chosen subset of those pairs after filtering ties and junk). The InstructGPT-style path trains a reward model on those pairs, then optimises the policy with PPO against that reward. DPO skips a separate reward fit and updates the policy directly with a preference loss on the same chosen/rejected pairs, anchored to a reference model. Collection and pairwise aggregation are shared; the optimiser diverges afterward.
Go deeper
- [2203.02155] Training language models to follow instructions with human feedback · arxiv.org
- [2305.18290] Direct Preference Optimization: Your Language Model is Secretly a Reward Model · arxiv.org
Image: Original diagram, The Daily Triptych. Licence: Original work. Source.