DPO Dataset Validator
Validate a preference dataset for DPO, ORPO or KTO training. Checks that every pair has both a chosen and a rejected completion, that they are not identical, that message roles are right, and reports repeated prompts. Handles the TRL prompt/chosen/rejected shape and OpenAI's preference format.
Validate
The three shapes it understands
- TRL text —
{"prompt": "…", "chosen": "…", "rejected": "…"}. The simplest form, and what most Hugging Face preference datasets use. - TRL conversational —
chosenandrejectedare arrays of{"role", "content"}messages, so the preference can cover a multi-turn exchange. - OpenAI preference —
{"input": {"messages": […]}, "preferred_output": […], "non_preferred_output": […]}, used by OpenAI's preference fine-tuning.
A file that mixes shapes is flagged: most trainers expect one shape throughout and will crash or silently skip records when they meet another.
What makes a preference pair useful
The validator catches structural problems. These are the content problems it cannot catch, and they matter just as much:
- The difference should be the thing you want to teach. If chosen is longer than rejected across your whole dataset, the model learns "be verbose" rather than "be correct". Check length distributions.
- Both completions should be plausible. A rejected answer that is obvious garbage teaches an easy boundary and wastes the pair.
- The prompt should be identical for both. In the TRL shapes there is one prompt by construction; in the OpenAI shape, make sure
inputreally is what produced both outputs. - Repeated prompts are fine — deliberately. Several preferences per prompt is a normal and useful pattern. The report counts them so you can confirm it is intentional rather than a duplication bug.
Where this sits in the pipeline
Preference tuning normally follows supervised fine-tuning. Validate the SFT file with the provider validators, split it with train / val / test split, and check for leakage between the splits before you trust any evaluation number.
Privacy
Nothing is uploaded. The whole thing runs in this tab, in your own browser. That matters here more than on most tool sites — training data is usually the most sensitive file a team owns.
Frequently asked questions
It says my record is not recognised, but it looks fine.
Auto-detect needs either chosen/rejected or preferred_output/non_preferred_output. Datasets that use other names — better/worse, response_a/response_b — need renaming first; Find & replace or key case conversion can do it.
Does DPO need a prompt field?
TRL supports implicit-prompt datasets where chosen and rejected each contain the full conversation, so a missing prompt is a warning rather than an error. Explicit prompts are less ambiguous and preferred.
Why warn about a non-assistant role in the output?
The completion being compared is normally the assistant's turn. A user or system role there usually means the arrays were assembled wrongly and the trainer will compare the wrong spans.
Can it check token counts?
Not here — use Token counter on the same file. Preference pairs are roughly twice the length of an SFT record, so context limits bite sooner than people expect.