- 1Split into train / dev / holdout, store as {prompt, chosen, rejected} triples, and freeze the seed used for candidate generation so the dataset is reproducible.
- 2Have humans (or a strong judge model) rank or pairwise compare the candidates per prompt, producing a chosen/rejected label for each pair.
- 3Filter pairs where the quality gap is too small to learn from (e.g. judge confidence below a threshold, or rubric tie), keeping only pairs with a clear preferred side.
- 4Deduplicate near identical chosen and rejected texts (and drop pairs where chosen is approximately rejected) so the model is not asked to learn distinctions between essentially the same answer.
- 5For each prompt, generate 4-8 candidate responses from the current SFT model at temperature ~1.0 to get genuine diversity, not near identical samples.
- 6Sample ~5,000 prompts from the production traffic distribution (or a proxy) so the trained preference signal matches what users actually ask.
Prompts first, then candidates, then labels, then two filtering passes (deduplication and quality-gap), then the final split. Each step depends on the artifact the previous step produced.
Think of judging a baking competition. You first invite contestants (the prompts), then collect their cakes (the candidate responses), then have judges score and rank them (the labels). Before you publish the results, you check that no two cakes are identical entries and that the winning cake is meaningfully better than the runner-up. Only then do you split the results into the official records and an audit set. Doing these steps out of order means judges score nothing, or you keep ties as wins, or you train your taste critic on noise. The sequence reflects what each step needs to exist first.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Direct preference optimization (DPO) is only as good as the preference data you train it on. The data pipeline that produces a clean DPO dataset has six logical steps, and the order among them is not a matter of taste; it is dictated by data dependencies. Each step consumes the output of the previous step and produces something the next step needs.
The order 0, 1, 2, 3, 4, 5 reflects this dependency chain: prompts first, then candidates, then labels, then two filtering passes, then the final train and dev split. Getting the order wrong typically means either skipping a step (training on noisy data) or doing a step before its inputs exist (impossible).
This deep dive walks through each step in order, the rationale for its placement, the common errors that come from misordering or skipping, and how this pipeline interacts with online DPO variants and with non-paired preference methods like KTO.
Step 0: source the prompts
Everything in a DPO dataset starts with a set of prompts. The choice of prompt distribution is one of the most consequential decisions in the pipeline because the trained preference signal will be calibrated against this distribution.
The right source is production traffic, or a proxy that closely matches it. If your product is a code-review assistant, prompts should look like code-review requests, not like general-chat questions. If your product is a customer-support bot for a specific app, prompts should match that app's actual support patterns.
A common error is to source prompts from public benchmarks alone (Anthropic-HH, UltraFeedback, ShareGPT). These are convenient because they are large and clean, but they reflect a generic chat distribution that may diverge from your actual users. The model trained on this preference data will optimise for the wrong target.
In practice, teams blend sources. Maybe 70% production traffic samples (lightly redacted for PII), 20% adversarial or edge-case prompts written by red-teamers, 10% public-benchmark prompts for coverage of categories the production distribution underweights. The blend is documented and revisited as the product evolves.
The scale at this step sets a soft cap on the whole pipeline. With 5,000 prompts and 6 candidates each, you have 30,000 candidates and roughly 15,000 to 30,000 pairs (depending on labelling scheme). The labelling budget often constrains how many prompts you can include.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- Anthropic's published RLHF data pipelines follow this same dependency order, with prompts sourced from production traces and candidates generated from successive policy versions.
- UltraFeedback, the most-cited open DPO dataset in 2026, uses a strong judge model for labelling and explicitly documents its near-duplicate and quality-gap filtering rules.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you decide between a strong judge model and human labellers for the labelling step, and how would you combine them?
Judge models are cheaper and faster but inherit their biases. The common pattern is judge-model labelling at scale with a small human spot-check on a random sample, plus dedicated human labelling on disagreement-prone categories.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Skipping the quality-gap filter and training on labelled pairs where the chosen and rejected responses are essentially tied. That teaches the model to chase noise rather than real preference signal.
60 second bullets to scan on the way to the call.
The six steps of DPO data curation in their dependency order
Why prompts must come from a distribution matching production traffic
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.