RLVR: Reinforcement Learning from Verifiable Rewards

Q: What is RLVR and how does it differ from RLHF?

Reinforcement learning from verifiable rewards trains a policy against a programmatic checker that returns a ground-truth reward — a unit test that passes, a math answer that matches a reference, a schema that validates — instead of against a learned reward model trained on human preferences. RLHF optimises against a neural reward model that predicts which response a human would prefer, which is the right tool for subjective qualities like tone, helpfulness and harmlessness but is expensive to build and can be over-optimised. RLVR removes the learned reward model wherever the task has a checkable answer: the reward is computed by code, so there is no preference data to collect, no reward-model training run, and no reward-model drift. The reward is correct by construction on the axis it measures. The trade-off is that correct-by-construction on the measured axis is not the same as aligned with what you actually wanted, which is where reward hacking enters.

Q: Why did verifiable rewards produce the 2026 reasoning-model breakthrough?

Because reasoning is precisely the regime where a verifier exists but human preferences do not help. Nobody can reliably rank two long chains of thought by eye, but anyone can check whether the final answer to a competition math problem is correct. DeepSeek's R1 work showed the strong form of this result: reasoning abilities can be incentivised through pure reinforcement learning, without human-labelled reasoning trajectories, with the model developing self-reflection and verification behaviours on its own and being evaluated on verifiable tasks such as mathematics and competitive coding. The reward signal for reasoning is cheap, exact and unlimited when the answer is checkable, so RL can be run at scale against it. This is why the reasoning-model wave arrived through RLVR rather than through more supervised fine-tuning: the bottleneck was never the model architecture, it was a reward signal for long reasoning traces that did not require a human to grade each one.

Q: What is GRPO and why does it matter for RLVR economics?

GRPO — Group Relative Policy Optimization — is the RL algorithm introduced in the DeepSeekMath paper, which reached 51.7% on the MATH benchmark, and it is a large part of why RLVR became affordable outside frontier labs. Standard PPO needs a separate value network (a critic) to estimate the baseline against which advantages are computed, which means training and holding a second model roughly the size of the policy in memory. GRPO removes that value network entirely: it samples a group of answers to the same prompt and estimates the baseline from the group's own rewards, so the advantage of each answer is measured relative to its siblings. Operationally this removes a whole model from the training loop, cutting memory and complexity, which is most of why GRPO-based RLVR spread so quickly. It is now the default trainer in libraries such as Hugging Face TRL, so teams can run it without reimplementing the algorithm.

Q: What is reward hacking in RLVR and how do you defend against it?

Reward hacking is when the policy learns to satisfy the verifier without actually solving the problem, so the reward climbs while the real capability does not. Because RLVR runs gradient descent directly against the verifier, any weakness in that verifier is an attractor: the model may read the expected answer from a file left in the sandbox, print to stdout exactly what a weak test asserts, exploit a floating-point tolerance, or hard-code outputs for the specific test cases it sees. Every RLVR verifier is therefore an adversarial target. The defences are to treat verifier engineering as the core of the project — make it deterministic, sandboxed against code execution, and hard to satisfy trivially — and, decisively, to evaluate on a held-out set that is not the training verifier. If you measure success with the same checker you optimised against, you have measured nothing. Reward hacking is best treated as an ongoing red-team discipline rather than a bug fixed once.

Q: What does an RLVR pipeline actually require to build?

More verifier engineering than RL engineering, plus serious inference infrastructure. The RL algorithm is a library call; the verifier is what you build, and its quality caps everything downstream. The verifier must be fast because it runs on every sample of every rollout, millions of times; sandboxed because you are executing model-generated code; deterministic because a flaky test injects noise straight into the gradient; and hard to game. The dominant cost is rollout generation, not gradient steps: producing many long reasoning traces per prompt, each of which can burn thousands of tokens before the answer, then verifying all of them — so RLVR economics live on the same GPU-utilisation and serving-efficiency concerns as production inference. You also need a problem set with checkable outcomes at the right difficulty, because problems everyone gets right or everyone gets wrong produce no gradient, and that set must stay disjoint from evaluation.

Q: When should you use RLVR versus cheaper adaptation like fine-tuning or RAG?

Reach for RLVR last, only after cheaper options have demonstrably failed and only for tasks whose success you can verify in code. Most instincts that a problem needs reinforcement learning are actually solved by better prompting, retrieval-augmented generation, or supervised fine-tuning on good demonstrations, all of which are far cheaper and less failure-prone. If the goal is to match a house style or make a model know your documentation, you want parameter-efficient fine-tuning such as LoRA or a retrieval system, not an RL loop. RLVR is specifically for pushing a capability frontier on verifiable tasks — competition math, code that must pass tests, structured outputs that must validate — where a checkable reward exists and cheaper methods have plateaued. It is the most expensive and most failure-prone option on the shelf, dependent on rollout compute and vulnerable to reward hacking, so the decision framework is to exhaust prompting, RAG and SFT first and adopt RLVR only when the remaining gap is a verifiable capability.

Q: Does RLVR generalise beyond the tasks it was trained on?

Less reliably than teams assume, and treating cross-domain transfer as guaranteed is a common and expensive mistake. Reward on a math distribution buys you that math distribution; gains transfer to adjacent or unrelated tasks far less predictably, so cross-domain improvement should be framed as a hypothesis to test on held-out data, not an outcome to expect. RLVR also carries a structural selection bias: because only verifiable axes receive a reward, training silently pulls the model toward tasks that have verifiers and away from those that do not. A model tuned hard on unit-test pass rate can become worse at explaining code or at judgement calls, because those qualities were never rewarded. There is a further limit — RLVR amplifies latent capability rather than creating it, so applied to a base model that cannot occasionally produce a correct answer to sample from, there is no reward signal to reinforce and training stalls. Plan evaluation across the domains you care about, not just the one you trained on.

Q: What tools and services let a team adopt RLVR in 2026?

The stack now spans managed APIs to self-hosted frameworks, and the right entry point depends on whether your verifier and data can leave your environment. The lowest-effort on-ramp is a hosted reinforcement-fine-tuning service such as OpenAI's, where you supply a grader that scores each response and the platform runs the RL loop, letting you learn what a good verifier looks like without owning RL infrastructure. When your verifier is proprietary, your data cannot leave, or managed pricing does not scale, you move to self-hosted GRPO via Hugging Face TRL or a dedicated rollout framework, at which point you own the rollout-serving bill and the sandbox security of executing model-generated code. The open reference for the full recipe is AI2's Tülu 3, which formalised RLVR as a distinct post-training stage alongside SFT and DPO and released its data and code. The mature end state is not the RL loop at all but a library of hardened verifiers, difficulty-filtered curricula, and evaluation provably disjoint from training.