RLVR składa się z trzech filarów. (1) Zbiór promptów z weryfikowalną odpowiedzią — math z ground truth (np. AIME, MATH), kod z testami jednostkowymi (HumanEval, LiveCodeBench), instrukcje format-strict (IFEval — czy odpowiedź ma listę punktów, JSON, dokładnie 5 zdań). (2) Funkcja nagrody R(x, y) → {0, 1} (lub kompozycja kilku komponentów R = α·R_correct + β·R_format) implementowana programistycznie — np. SymPy do porównania wzorów matematycznych, sandbox do wykonania `pytest`, regex do format checks. (3) Algorytm policy-gradient — w pracach Tülu 3 użyto PPO; DeepSeek-R1 zastosował GRPO; inne implementacje używają REINFORCE++. Trening: model π_θ generuje rollouty na promptach z verifierem, otrzymuje 0/1 reward, polityka jest aktualizowana z KL-penalty wobec π_ref (zazwyczaj SFT). Tülu 3 pokazuje, że RLVR działa nie tylko na reasoning (math/code), ale też na ścisłe instruction-following — domena, w której DPO i RLHF zwykle zawodzą („policz dokładnie 5 słów", „odpowiedz tylko TAK lub NIE"). Kluczowa różnica wobec Reasoning RL: RLVR jest pojęciem ŚREDNIEJ klasy abstrakcji — opisuje rodzinę algorytmów, nie konkretną implementację (Reasoning RL = paradygmat dla reasoning + RLVR jako mechanizm; GRPO = konkretny algorytm w obrębie RLVR).
Klasyczne RLHF wymaga uczonego modelu nagrody (reward model) — drogiego w treningu, podatnego na overfitting i reward hacking, zależnego od jakości par preferencji. Dla wielu zadań — matematyka, kod, ścisłe wymagania formatu — istnieje jednak naturalny weryfikator (`==`, `pytest`, regex), który daje sygnał poprawności bez ludzkiej etykiety. RLVR systematyzuje ten obszar: definiuje funkcje nagrody jako rzecz pierwszej klasy w pipeline, dopuszcza dowolne policy-gradient algorytmy (PPO, GRPO, REINFORCE++) i pokazuje, że dla zadań zweryfikowalnych RLVR daje czystszy sygnał, mniejsze ryzyko reward hackingu i znacząco taniej niż RLHF.
Programistyczna funkcja oceniająca poprawność rolloutu y dla promptu x. Bez parametrów uczonych. Definiuje cały RLVR — wszystko inne (algorytm, model, sampler) jest zamienne.
Oficjalna
Datasets z parami (prompt, ground truth) lub (prompt, verifier function). Tülu 3 ujawnia własny mix: math (NuminaMath, MATH), code (LiveCodeBench), instruction-following (IFEval prompts).
Mechanizm aktualizujący politykę na podstawie nagród z verifiera. Dowolny on-policy algorytm — PPO (Tülu 3), GRPO (DeepSeek), REINFORCE++ (Kimi).
Oficjalna
Krytyczna infrastruktura dla code verifierów: subprocess z timeout, cgroups, izolacja sieci, ban niebezpiecznych importów. Bezpieczeństwo verifiera jest często pomijane, a wycieki/exploity stąd są realne.
Oficjalna
Najpoważniejsza pułapka. Klasyczne dziury: hardkodowanie odpowiedzi z testów (`assert answer == 42`), formatowanie odpowiedzi by oszukać regex (np. zawsze `\boxed{}`), generowanie krótkich szumnych odpowiedzi które przypadkiem trafiają. Trening „rośnie" w reward, ale model staje się gorszy.
Verifier wykonuje kod generowany przez LLM. Bez izolacji (timeout, ban network, cgroups, no filesystem write) model może wpłynąć na infrastrukturę treningową, exfiltrować dane lub zniszczyć rolloutry innych zadań.
Trening tylko na math daje świetnego matematyka, który gubi się w reszcie zadań. Tülu 3 explicite pokazuje, że mieszanka domen (math + code + IFEval + general QA) jest niezbędna.
Gdy wszystkie rolloutry dla danego promptu dostają tę samą nagrodę (wszystkie poprawne lub wszystkie błędne), advantage = 0 i prompt nie wnosi gradientu. Tülu 3 i DAPO filtrują takie prompty (dynamic sampling) lub używają temperatury, by zwiększyć wariancję.
OpenAI ustanawia standard RLHF z trenowanym reward modelem na parach preferencji. RLVR powstanie jako kontrapunkt: reward jako rule, nie model.
DeepSeek wprowadza GRPO z rule-based rewards dla matematyki. Praktyczna pre-implementacja idei RLVR, choć bez nazwy.
Allen AI publikuje Tülu 3 (arXiv:2411.15124, listopad 2024) i nadaje paradygmatowi nazwę: Reinforcement Learning with Verifiable Rewards. Pokazują, że RLVR działa nie tylko na reasoning, ale też na precyzyjne instruction following (IFEval) — gdzie DPO/RLHF zawodzą.
Styczeń 2025: DeepSeek-R1 stosuje RLVR (przez GRPO) na MoE 671B i wywołuje lawinę reprodukcji. Termin „RLVR" zostaje powszechnie zaadoptowany w środowisku open-source.
RLVR staje się standardową ścieżką post-treningu dla open-source LLM o silnym reasoning + instruction following. OLMoE-instruct, Llama 3 Tülu, OpenR1 i SimpleRL reprodukują pipeline na różnej skali.
Powstają dedykowane zbiory: TÜLU 3 SFT mix, IFEval-Hard, RewardBench v2 — każdy z osobnym verifierem. Verifier-as-data-pipeline staje się odrębną dyscypliną.
Złożoność czasowa: O(N · L · |θ|) sampling + O(N · V) verifier + O(N · L · |θ|) update. Złożoność przestrzenna: O(2 · |θ|) (policy + reference) + verifier RAM (mała).
Bottleneck zależy od domeny. Math/regex: dominuje sampling LLM. Code: dominuje verifier (równolegle w sandbox'ach CPU). Dla mieszanych domen — produkcyjny pipeline ma osobny cluster GPU dla LLM i osobny cluster CPU dla sandbox'ów verifiera, połączone async queue.
Najważniejsza decyzja w RLVR. Kompozycja: R = α·R_correct + β·R_format + γ·R_constraints. Słaby/szumny verifier → reward hacking poziomu zadania (np. „pisz wszystko w boxed{}" zamiast rozumować).
Wybór policy-gradient algorytmu. PPO (Tülu 3), GRPO (DeepSeek), REINFORCE++ (Kimi k1.5). RLVR jest agnostyczne wobec algorytmu — definiuje sygnał nagrody, nie sposób aktualizacji.
Domena zadań z verifierem. Tülu 3 wprowadza shadow domain — instruction-following — obok klasycznego math/code. Mieszanka domen w treningu daje bardziej uniwersalne modele.
Sposób łączenia kilku komponentów nagrody. Suma ważona, dyskretna kompozycja (binarne AND), lub hierarchiczna (najpierw format, potem correctness).
Dla code verifierów: timeout na test (typowo 10–60s), izolacja sieciowa, ograniczenia pamięci (cgroups), ban niebezpiecznych importów. Bezpieczny sandbox jest niezbędny — verifier wykonuje kod generowany przez LLM.
RLVR to mechanizm sygnału nagrody, nie struktura modelu. Polityka i model referencyjny są standardowe (gęste lub MoE). Można łączyć z dowolną architekturą.
Produkcyjne pipeline'y (Tülu 3, DeepSeek-R1) skalują verifier osobno: cluster sandbox'ów Python wykonuje pytest na rolloutach asynchronicznie wobec klastra inferencji vLLM.
RLVR jest typowym RL dla LLM — sampling i trening dominują GPU. Verifier działa na CPU obok klastra GPU (sandbox'y Python).
Verifiery (pytest, SymPy, regex) są CPU-bound. Klastry verifierów skalują się niezależnie od GPU dla treningu.
Sama metoda jest agnostyczna — dowolny RL framework + dowolny verifier. Specyfika sprzętowa wynika z LLM + RL, nie z RLVR per se.
