A reward model typically keeps the base transformer and adds one scalar-valued head that outputs a single reward score per candidate completion.
Think of a school essay checker. The essay itself is read by a big language system, but at the end a tiny extra module gives one final score. That tiny module is the new head. In RLHF, engineers usually keep the original transformer and add this scoring head so each answer gets one number. Training then teaches that number to go up for preferred answers and down for rejected ones.
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.
Most interview answers about the standard reward-model architecture are technically correct but operationally shallow. They name one formula, then stop before discussing how data quality, metric choice, and optimization pressure determine whether the system actually improves user outcomes. In real post-training pipelines, that missing middle is where most failures happen.
The core question here is why teams reuse a pretrained transformer backbone and add a scalar head for preference ranking. To answer it well, you need to connect mechanism to deployment reality: what signal is learned, why that signal can drift, and which guardrails keep optimization honest. This deep dive walks from foundations to production checks so the concept is not just memorized, but usable in design reviews and interview discussions.
Mechanism and objective: what is actually optimized
Start with the optimization target, because confusion here causes downstream mistakes. In this topic, the learning loop is built around shared tokenizer, pretrained backbone, pooled hidden representation, scalar reward head, and pairwise loss over chosen-rejected outputs. That list sounds simple, but each element constrains what the model can and cannot learn. If you are clear on the target signal, many design choices become obvious instead of hand-wavy.
A useful interview move is to separate absolute quality from relative preference. Many alignment objectives do not teach a universal quality score; they teach ordering under specific label policies. That means calibration, coverage, and disagreement handling are first-class concerns, not afterthoughts. When teams forget this, they celebrate metric gains that fail to transfer to users.
The mathematical form below captures the mechanism compactly. Treat it as a map of assumptions: if labels are noisy, if distributions shift, or if optimization pressure is too strong, the same equation can still produce poor behavior. The formula is necessary for precision, but governance around it is what keeps the system useful.
r_\theta(x,y)=w^T h_{EOS}(x,y)+bSituations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- OpenAI's InstructGPT setup used a transformer-based reward model with scalar scoring over completions.
- Many open RLHF repos follow the same pattern: shared LM backbone plus one reward head for ranking.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat pooling choice is common before the scalar reward head?
Mention EOS or last-token pooling and explain consistency requirements across training and inference.
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.
Confusing the reward-model head with a token-by-token decoder head leads to wrong architecture assumptions.
60 second bullets to scan on the way to the call.
Backbone reuse in reward models
Scalar head purpose in RLHF
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.