DPO Derivation › Reparameterizing the Reward
Language AI HandbookAll chapters DPO Derivation › Reparameterizing the RewardOne section · Sections in this chapter4 / 12 ↓
Reading tools Definitions & inline links
Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.
Article links
Make inline references clickable
The next step uses the relationship between the optimal policy and the reward function in reverse. Given an optimal policy, we can solve for the reward function it implies.
This reverse direction might seem like a mathematical curiosity, but it turns out to be the key insight that makes DPO possible. If we can express the reward purely in terms of policies (without needing to train a separate reward model), then we can substitute this expression into the preference model and optimize directly. The reward becomes implicit in the policy rather than explicit in a separate neural network.
Think of it this way: the optimal policy and the reward function are two sides of the same coin. Knowing one completely determines the other, up to an additive constant per prompt. The optimal policy is just a "softmax" over rewards (scaled by ) relative to the reference. Inverting that relationship is like going from probabilities back to log-probabilities: algebraically straightforward once you know the connection exists.
Starting from:
where:
- : the optimal policy distribution
- : the partition function
- : the reference policy distribution
- : the reward function
- : the temperature parameter
We can rearrange to isolate the reward. First, take the log of both sides:
where:
- : log-probability under the optimal policy
- : log-probability under the reference policy
- : the reward function
- : the KL penalty coefficient
- : log of the partition function (depends only on )
Taking the logarithm turns our multiplicative relationship into an additive one. This makes algebraic manipulation simpler. The logarithm of a product becomes a sum of logarithms, and the logarithm of the exponential simply returns its argument.
Now, we rearrange terms to solve for :
where:
- : the implicit reward
- : the KL penalty coefficient
- : the optimal policy
- : the reference policy
- : the partition function
- : the scaled log-ratio term
This is the reward reparameterization. It tells us that for any optimal policy , we can express the implicit reward purely in terms of log probability ratios, plus a prompt-dependent constant .
The log ratio has a natural interpretation: it measures how much the optimal policy has increased or decreased the probability of response compared to the reference. Responses that the optimal policy strongly prefers will have large positive log ratios, while responses it disfavors will have large negative log ratios. This log ratio, scaled by , gives us the implicit reward up to an additive constant.
The partition function doesn't depend on ; it only depends on the prompt . This will turn out to be important because when we compute preference probabilities, this term cancels out.
Why This Reparameterization Is Significant
The reward reparameterization eliminates the need for an explicit reward model. In standard RLHF, you train a separate neural network on human preference data, and then you use that trained reward model to provide training signal to the language model policy. That two-step pipeline doubles the computational cost, introduces an additional source of approximation error, and creates the reward hacking problem when the policy finds outputs that score well on but do not match human preferences.
The reparameterization shows that you never needed a separate reward model. The reward is already encoded in the ratio between two language models: the policy being trained and the reference model. Every time you update the policy's weights, the implicit reward function changes accordingly. The reward model and the policy are the same object, just viewed from different angles. This is the deep reason why DPO is simpler than RLHF: it reduces the engineering work and the number of conceptual entities you have to reason about.