Zenaique

Order the steps in building a 5k pair DPO dataset on helpfulness.

Order steps·Medium·4.0 · 0·~1 min·Asked atOpenAISamsungSiemens·Relevant atAnthropicCohereGoogleMeta
Attempt it
  • 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.
TL;DR

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.

Memory aid
Sign in to see the mnemonic that makes this stick.
Easy to grasp

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.

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.

Step 1: generate candidate responses
Step 2: label the candidates
Step 3: deduplicate near-identical pairs
Step 4: filter low-confidence pairs
Step 5: split, store, and freeze
Sign in to unlock the full deep dive.

Situations where this technique stops working.

Sign in to see when this approach fails.

2–4 min · Everything important, quickly.

Sign in to see the quick scan of the deep dive.

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.
Sign in to see more production examples.

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?
A

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.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

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.

Sign in to see all red flags and common mistakes.

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

Sign in to unlock the revision sheet.

Primary sources. Browse if you want the original framing.

Similar questions

Same topic, related formats. Practice these next.

4 curated
Next question
What is RLHF, and why is it used after pretraining?
MCQ·Easy