DPO needs two things RLHF also needed: PAIRED preference data ("A beats B," not just "A is good") and a frozen REFERENCE model to measure drift against. Both are real costs. What happens if a method drops one of them?
The same 3 comparisons DPO's chapter used — "B beats A," "B beats C," "C beats A" — but relabeled as 6 completely independent judgments: each response is just "desirable" or "undesirable," on its own, with no memory of which other response it was compared against. Step through them one at a time.
KTO (short for Kahneman-Tversky Optimization) keeps DPO's reference-relative log-ratio and its logistic loss shape, but scores ONE response at a time instead of a pair:
SimPO (short for Simple Preference Optimization) keeps DPO's pairing, but drops the reference model entirely — the implicit reward is a response's OWN length-normalized log-probability, compared against a fixed target margin :
- — KTO's sign flip: for a desirable response, for an undesirable one — the only place pairing information used to live.
- — the single response being judged, in KTO; , — the winning and losing responses of a pair, in SimPO.
- — the frozen reference model DPO and KTO both compare against; SimPO has no such term at all.
- — the response's length in tokens, used to normalize its log-probability so longer responses aren't penalized just for being longer.
- — SimPO's fixed target reward margin, replacing the role a reference model's baseline would otherwise play.
- KTO drops PAIRING
Each of DPO's comparisons becomes two independent examples: the winner labeled desirable, the loser labeled undesirable. Only one response's log-ratio is touched per update — there's no "loser" to simultaneously push down in the same step, because pairing information was thrown away.
- SimPO drops the REFERENCE MODEL
Instead of , SimPO uses alone, divided by length. No second frozen copy of the model needs to be kept in memory during training at all.
- Both keep DPO's core trick
Neither method needs a separately trained reward model — like DPO, the loss is computed directly on the policy's own log-probabilities.
Both variants still recover roughly DPO's ranking — preferred, then , then — using strictly less machinery than DPO started with: KTO drops the paired structure, SimPO drops the reference model. Neither is strictly "better" than DPO; each is a different cost DPO's original formulation was willing to pay, removed.
KTO's very first example, " is desirable," starting from a uniform policy:
- At initialization, the policy IS the reference
, so the log-ratio is . With for "desirable," , so .
- The update touches ONLY B
— identical in magnitude to DPO's very first update, but and are untouched here; DPO's paired update would have pushed a loser DOWN by the same amount in the same step.
- After all 6 examples
The same one-response-at-a-time update, run through the remaining 5 examples in order:
- Example 2, " undesirable": (softmax has already shifted after 's update), log-ratio , , , update
- Example 3, " desirable" again: , log-ratio , , , update
- Example 4, " undesirable": , log-ratio , , , update
- Example 5, " desirable": , log-ratio , , , update
- Example 6, " undesirable" again: , log-ratio , , , update
Final values:
The same ordering DPO found, recovered without ever using a preference pair.
After KTO training on the 6 unpaired examples derived from 3 comparisons, find the arm with the lowest preference parameter.
DPO, KTO, and SimPO are three points on the same spectrum, not three unrelated ideas: DPO needs paired data and a reference model; KTO trades pairing for the ability to use ordinary desirable/undesirable labels; SimPO trades the reference model for a length-normalized reward and a fixed target margin. Every one of them still needs preference OR feedback data collected up front. The next chapters move to a different source of signal entirely — reward that can be checked by a program, not judged by a person.