Understanding Reasoning from Pretraining to Post-Training
Abstract: Reinforcement learning (RL) has become central to improving LLMs on complex reasoning tasks, yet RL post-training is largely studied in isolation from the pretraining that precedes it. As a result, two basic questions remain open: (1) how do pretraining choices (model size, data) shape the returns to RL compute, and (2) what does RL actually do to the model? These questions are difficult to study in the standard LLM setting: pretraining corpora are vast and uncontrolled, making it hard to attribute behaviors to pretraining versus RL, and systematic compute sweeps across both stages are prohibitively expensive. To address these challenges, we use chess as a controlled testbed for studying reasoning across the full pretraining-to-post-training pipeline. We follow the standard LLM training pipeline by pretraining LLMs from 5M to 1B parameters on human chess games, supervised fine-tuning on synthetic reasoning traces, and running RL on chess puzzles with verifiable rewards. Using this framework, we find that the post-RL performance at given RL compute level is well-predicted from the pretraining loss, and slope of the RL reward curves improves approximately linearly with the pretraining tokens. Beyond scaling, we find that RL does not simply sharpen the SFT policy: on easy puzzles it amplifies correct moves the SFT policy already preferred, while on hard puzzles it surfaces correct moves that were nearly absent under SFT. We further test whether our findings transfer beyond chess by training a 1B LLM on math-domain text, where the same predictive pattern emerges: longer-pretrained checkpoints reach higher post-RL performance and improve faster under RL. In sum, we provide a quantitative account of the pretraining-to-RL interface and a controlled testbed for studying the science of reasoning across the full pretraining-to-post-training pipeline.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What this paper is about
This paper asks a simple, important question about training thinking AIs: if you first teach a model by letting it “read” lots of examples (pretraining) and then let it “practice” with feedback (reinforcement learning, or RL), how do these two stages work together? The authors build a clear, controlled test case using chess to measure, step by step, how pretraining and RL shape a model’s ability to reason.
The main questions
The researchers focus on two key questions:
- How do choices made during pretraining (like model size and how much data it reads) affect how much RL can help later?
- What does RL actually change in the model’s behavior—does it just sharpen what the model already prefers, or can it help the model find new, better ideas it didn’t really use before?
What they did (in everyday terms)
Think of the training pipeline like learning chess yourself:
- Pretraining: “Reading a lot of games”
- The model looks at millions of human chess games and learns what moves usually happen. This is like a student absorbing patterns by replaying many expert games.
- Supervised fine-tuning (SFT): “Thinking out loud”
- Before making a move, the model is trained to write a short, move-by-move “thought process” (but using chess move tokens, not words). This is like being taught to explore a few possible lines before choosing one.
- Reinforcement learning (RL): “Puzzle practice with strict feedback”
- The model solves chess puzzles where there’s a single best move at each step. It only gets a reward if it gets every move in the solution right. That’s like a coach who gives you a thumbs-up only if your entire solution is perfect—one mistake and you get zero points.
- They use a standard RL method (you can think of it as a way to nudge the model toward strategies that lead to perfect puzzle solves more often).
Why chess?
- Chess is perfect for this study because moves are clear, the set of legal actions is small and exact, and a strong chess engine can tell you whether each move is right or wrong at every step. That makes it easy to see how the model’s “thinking” changes.
They trained many models (from tiny to about 1 billion parameters) and tried many combinations of how much to pretrain and how much RL to do, so they could see patterns across scales.
Helpful terms:
- “pass@1” means “did the model get it right on its first try?”
- “pass@k” means “did the model get it right in k tries if we let it try multiple answers?”
- A “scaling law” is a rule-of-thumb that predicts how performance changes as you increase model size, data, or compute.
The main findings
- A joint rule connecting pretraining and RL
- The better the model’s pretraining (measured by lower pretraining loss—basically, how well it predicts moves in unseen human games), the higher its puzzle-solving performance after a fixed amount of RL. In other words: better “reading” makes later “practice” more effective.
- The speed at which RL improves the model (how fast pass@1 goes up as you spend more RL compute) grows roughly linearly with how many pretraining tokens the model saw. Put simply: more reading makes practice work faster.
Why this matters: If you know how good your pretraining is, you can predict how well RL will turn that into puzzle-solving skill.
- How to split your “training budget” between pretraining and RL
- With a small total budget, investing more in pretraining pays off (you need a strong starting point).
- As the total budget grows, it becomes better to spend a larger fraction on RL—practice becomes increasingly valuable once the base skill is strong.
- For “pass@1” (first-try success), RL helps a lot. For “pass@k” (success with more tries), extra pretraining often helps more than extra RL.
- What RL actually changes in the model’s decisions
- On easy puzzles, RL mostly amplifies correct moves the model already liked (it sharpens its top choice).
- On hard puzzles, RL can sometimes “surface” the right move even if the model barely considered it before—good! But RL can also strengthen wrong-but-confident moves—bad!
- This mix explains a key pattern: pass@1 tends to improve, but pass@k doesn’t always get better, because RL may concentrate probability on fewer moves (even if they’re not always the right ones).
- Beyond chess: similar patterns in math
- They repeated the idea with a 1B-parameter LLM trained on math problems. The same predictive pattern showed up: better/longer pretraining led to higher post-RL performance and faster gains during RL.
Why these results are important
- Planning your compute: The paper offers a practical guide for splitting training effort between pretraining and RL. Early on, build a strong base; later, spend more on RL to polish and extend capabilities.
- Understanding RL’s role: RL doesn’t just “make the model more confident.” It can both help the model find rare but correct moves (great for hard tasks) and sometimes double down on wrong ideas (a risk to manage).
- Designing better training: If you want higher pass@k, you might need to improve pretraining or adjust RL so it doesn’t collapse too hard onto a few options. Techniques that discourage “wrong-mode amplification” could make RL more broadly beneficial.
- Generalization: Because similar trends show up in math, these ideas likely apply to many reasoning tasks, not just chess.
In short
- Stronger pretraining sets a better stage for RL.
- More pretraining tokens make RL learn faster.
- As you have more total compute, shift more toward RL—but don’t neglect pretraining.
- RL boosts first-try accuracy a lot, but might not improve “many-try” accuracy unless you control for reinforcing wrong moves.
- The same story seems to hold in other reasoning domains, like math.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a single, actionable list of what remains missing, uncertain, or unexplored in the paper’s findings.
- External validity beyond chess puzzles: does the joint pretraining–RL scaling law hold for tasks without verifiable rewards (e.g., preference-based RLHF), for code/science reasoning, multimodal tasks, or very large action spaces typical of natural language?
- Frontier-scale behavior: the study covers models up to 1B parameters and RL runs for 20M–680M; does the law persist, change form, or saturate for larger models (e.g., 7B–70B+) and orders-of-magnitude more pretraining/RL compute?
- Full-curve RL scaling: the log-linear (early-regime) fit avoids the long-run sigmoid ceiling; can longer RL runs establish whether the same predictors (pretraining loss, tokens, size) also determine the asymptotic performance and the transition to saturation?
- Algorithmic specificity: results are based on GRPO; do the scaling relationships and policy-evolution patterns hold across other RL algorithms (PPO variants, A2C, Q-learning, DPO/RLAIF, process-supervision RL) and hyperparameter regimes (KL/entropy coefficients, group size, baselines)?
- Reward design sensitivity: the binary, all-or-nothing reward enforces exact solution lines; how do results change with stepwise/dense rewards, partial credit, or engine-based thresholds that accept multiple winning moves?
- Diversity vs pass@k under RL: pass@16 often stalls or degrades; which training interventions (entropy bonuses, KL regularization to SFT, diversity-promoting objectives, replay/mixture policies, ensemble methods) improve large-k coverage without sacrificing pass@1?
- Inference-time compute tradeoffs: how should practitioners allocate compute between training-time RL and inference-time sampling/search (Best-of-N, temperature, MCTS/beam search), and how do these choices shift the compute-optimal frontier?
- SFT reasoning-trace generation: CoT traces are synthesized from a proposal policy; what is the effect of proposal strength, number of samples K, ordering/serialization, or using engine/human-produced trees; is CoT necessary or can alternative SFT targets match RL scaling?
- Data composition and quality: pretraining uses 54B Lichess Blitz/Rapid tokens without systematic ablations; how do Elo filters, game length, openings, deduplication, noise, or adding engine/self-play games affect the predicted RL slope and post-RL performance?
- Action representation: moves are serialized into 4 tokens (vocab 81) and opponent moves are masked during SFT; do alternative tokenizations, including opponent modeling losses or richer state/action encodings, change scaling or policy evolution?
- Task scope: puzzles emphasize short-horizon tactics; do findings extend to long-horizon strategic play, endgames, or full-game self-play (e.g., ELO evaluations), and how does horizon length affect RL scaling and diversity?
- Wrong-mode amplification: RL can reinforce incorrect modes on hard puzzles; which mitigations (uncertainty penalties, conservative/implicit-Q methods, disagreement regularization, negative sampling on dominant wrong modes) reduce this effect and boost pass@k?
- Mechanistic understanding: the temperature-scaling test shows only moderate R2 and per-state heterogeneity; what circuit- or representation-level changes drive tail discovery or wrong-mode amplification, and can causal interventions validate these mechanisms?
- Statistical robustness: the paper does not report multi-seed variance, CIs, or sensitivity analyses; how stable are the fitted law parameters and policy-change taxonomies across seeds, k in top-k (beyond k=3), and εtail choices?
- Chinchilla dependence: frontier extrapolation assumes Chinchilla-style pretraining loss scaling; how sensitive are conclusions to deviations from that law, alternative fits in this domain, or data-mixture shifts?
- Cost realism: compute allocation is in FLOPs, while RL and pretraining differ in wall-clock/system overheads; how do recommendations change under dollar cost, energy, latency, or hardware constraints?
- Benchmark coverage and OOD generalization: the evaluation uses B1–B4 aggregates and a single curated source; how do results change on harder B5 subsets, different puzzle sources/years/engines, or adversarial/OOD puzzles?
- Depth of reasoning: RL improved breadth more than depth, and struggles beyond ~5 moves; what SFT/RL designs (curricula over horizon, depth-incentivizing rewards, trace shaping, multi-step verifiers) improve long-horizon search in-context?
- Transfer scope in text: the math study uses one 1B model, one recipe, and verifiable datasets; does the scaling relation hold for larger LMs, other domains (code, scientific QA), alternative RL signals (verifier-guided, preference models), and different CoT styles?
- Alternative evaluation metrics: beyond pass@k, do coverage/recall-of-good-moves, calibration, and decision-quality under perturbations align with the scaling law; can richer metrics better diagnose diversity collapse?
- Curriculum and data scheduling: does scheduling puzzle difficulty or mixing SFT/RL phases (interleaved training, staged curricula) change the compute-optimal split or reduce wrong-mode amplification?
- Seeded trace variety: the policy-evolution analysis marginalizes over 128 traces; is this sufficient, and how does increasing samples or using unbiased marginalization affect conclusions about policy change categories?
- Multiple-correct-move ambiguity: many positions admit several strong moves; using a single “ground-truth” line may mislabel valid alternatives; can engine-eval baselines or equivalence classes reduce label noise and its effect on RL behavior?
- Architecture invariance: results are on dense Qwen3 and OLMo-2; do MoE, recurrent/state-space, or retrieval-augmented architectures exhibit the same pretraining–RL interactions and optimal compute splits?
- Safety and reward hacking: with strict rewards, RL might learn spurious shortcuts; are there detectable failure modes (e.g., pattern exploitation) and verifier checks to prevent them in both chess and text domains?
- Generality of the slope law: the observed B ∝ a·log T + b·log N holds locally and weakens near saturation; where does this relationship break, and can a unified global law capture both early and late RL regimes?
Practical Applications
Immediate Applications
Below are concrete ways practitioners can use the paper’s findings and artifacts right now. Each item names the sector(s), suggests tools/products/workflows, and lists assumptions/dependencies that affect feasibility.
- Compute allocation planner for pretraining vs RL (software/AI, finance/ops)
- What to do: Use the joint pretraining–RL scaling law to decide how to split a fixed compute budget between pretraining tokens and RL steps for a given model size. Start RL later (with stronger checkpoints) when budgets are small; shift a larger fraction to RL as total compute grows.
- Tool/product/workflow: “Pre-to-Post Planner” script that ingests (N, T, pretraining loss, target RL compute) and outputs a recommended split, expected pass@1, and sensitivity analysis. Integrate into MLOps dashboards for training recipe selection.
- Assumptions/dependencies: Requires access to validation loss from pretraining and early RL curves to fit the local log-linear trend; law calibrated in chess and qualitatively validated in math—teams should re-fit on their own domain/task.
- RL readiness scoring for checkpoint triage (software/AI, academia)
- What to do: Rank pretrained checkpoints by their expected post-RL performance using validation loss as predictor; warm-start RL from the checkpoint with the lowest loss under a fixed RL budget.
- Tool/product/workflow: “RL Readiness Score” alongside each checkpoint in model registries to inform which checkpoint to promote to RL.
- Assumptions/dependencies: Pretraining loss must be comparable across checkpoints; predictor is strongest for pass@1 and higher RL budgets; may be weaker if evaluation is saturated or rewards are not verifiable.
- Early RL monitoring and auto–early stopping (software/AI)
- What to do: Fit the local log-linear RL scaling (reward vs log RL compute) from the first few hundred/thousand steps and terminate or adjust when projected gains flatten.
- Tool/product/workflow: Training loop plugin that fits slope B and intercept Rref on-the-fly and triggers early stop or compute reallocation.
- Assumptions/dependencies: Requires steady reward signal and stable evaluation; more reliable when reward curves haven’t reached saturation.
- Adopt synthetic, in-domain chain-of-thought traces to improve pass@k (software/AI, education)
- What to do: Build reasoning traces from sampled continuations in the domain’s own token space (e.g., moves in chess, solution steps in math/code) and SFT on trace+target to boost sample diversity and pass@k.
- Tool/product/workflow: “Reasoning Trace Synthesizer” that samples K continuations, merges them into a prefix tree, serializes breadth-first or depth-first, and appends the correct continuation as the final target.
- Assumptions/dependencies: Domain must permit serializing valid partial trajectories, and you must identify the “best” continuation to supervise. Improvements are strongest when traces reflect the model’s distribution (proposal policy) and when the domain supports explicit stepwise tokens.
- RL policy diagnostics to avoid pass@k regressions (software/AI, safety)
- What to do: Use the paper’s taxonomy to monitor whether RL is (a) amplifying correct top modes, (b) surfacing correct tail moves, or (c) amplifying wrong modes—especially on harder items where pass@k often stagnates or regresses.
- Tool/product/workflow: “Policy Evolution Dashboard” tracking the share of states in each category, with alerts when wrong-mode amplification rises; add regularizers (e.g., entropy/coverage penalties, mixture-of-objectives, KL controls) if diversity collapses.
- Assumptions/dependencies: Needs stepwise evaluation of candidate actions and a way to marginalize over reasoning traces; stronger signal in domains with verifiable step-level correctness.
- Benchmarking and curriculum design with difficulty bins (academia, education, product teams)
- What to do: Evaluate and train with stratified difficulty bins. Expect RL to help pass@1 first on easier bins; use SFT/trace quality and data scaling to support pass@k and harder bins.
- Tool/product/workflow: Difficulty-aware datasets and curricula (B1–B5-like bins) for reasoning tasks; adaptive training that increases hard-bin sampling after SFT stabilizes.
- Assumptions/dependencies: Requires reliable difficulty estimation; ensure train/val/test splits are de-duplicated at state/position level to prevent contamination.
- Planning and transparency for AI labs and public compute centers (policy, funding bodies)
- What to do: Require reporting of pretraining vs RL compute splits, pass@1 vs pass@k, and difficulty-binned results in model cards and grant deliverables; plan procurement with growing RL fractions as budgets scale.
- Tool/product/workflow: Standardized “compute allocation” and “post-training effect” sections in model documentation; review checklists for funding proposals.
- Assumptions/dependencies: Organizations must log FLOPs across stages; norms must value pass@k and diversity (not only pass@1).
- Turnkey chess/math tutoring features (education, consumer apps)
- What to do: Integrate in-token reasoning traces for explainable hints, staged breadth-first exploration, and verifiable move/step checking; tailor drills by difficulty where RL gives largest pass@1 gains.
- Tool/product/workflow: Chess puzzle tutors that show compact move-tree sketches; math solvers that reveal structured step trees with unit/result checks.
- Assumptions/dependencies: Access to engines/graders for verifiable correctness; careful UI to show trace excerpts without overwhelming users.
Long-Term Applications
These are promising, but need further research, scaling, domain adaptation, or infrastructure.
- Cross-domain “experience planning” in verifiable environments (software/AI, robotics, coding, OR)
- What to do: Generalize the joint scaling law to domains with compact action spaces and verifiable rewards, e.g., code generation with unit tests, formal theorem proving, program synthesis, SAT/SMT solving, circuit/layout optimization, operations research with simulators.
- Tool/product/workflow: “Experience Budgeter” that predicts returns to more pretraining vs more RL episodes for each domain/task; automatically tunes the RL fraction as total compute grows.
- Assumptions/dependencies: Must validate the law per domain; requires strong verifiers/simulators; action spaces might need domain-specific tokenization; transfer beyond chess/math is promising but unproven.
- Robust pass@k preservation during RL for generative assistants (software/AI, safety, product)
- What to do: Design RL objectives that improve pass@1 without collapsing diversity (e.g., explicit coverage targets, top-k-aware rewards, ensemble or BoN-aware training, diversity-constrained policy updates).
- Tool/product/workflow: “Coverage-Aware RL” libraries that combine GRPO/PPO with diversity controls and wrong-mode mitigation, monitored by the paper’s policy-change taxonomy.
- Assumptions/dependencies: Requires careful reward shaping and evaluation; risk of reward hacking and mode instabilities on open-ended tasks.
- Structured reasoning traces for code and multimodal tasks (software/AI, education)
- What to do: Replace free-form natural-language CoT with structured, domain-native traces: AST steps for code, formal proof states for math/theorem proving, tool-call graphs for agents.
- Tool/product/workflow: “Structured-CoT Compilers” that convert sampled continuations into compact, verifiable trees and train models to plan before committing.
- Assumptions/dependencies: Tooling to serialize and check partial states; availability of ground-truth continuations (gold or engine-verified).
- RL forecasting and compute-autotuning services (software/AI infrastructure, cloud)
- What to do: Offer services that infer the local RL slope B from a handful of steps and auto-adjust the RL share, batch sizes, and curriculum to hit target performance/cost trade-offs.
- Tool/product/workflow: Managed “Auto-RL Planner” integrated into training stacks; cost/performance SLAs based on fitted curves.
- Assumptions/dependencies: Requires consistent telemetry, reproducible eval, and per-domain calibration; curves can shift with algorithmic changes.
- Safety and governance benchmarks for post-training (policy, standards)
- What to do: Create standards that (a) report pass@1 vs pass@k, (b) disclose pretraining loss and RL fractions, (c) quantify wrong-mode amplification, and (d) mandate difficulty-stratified evaluations for reasoning systems used in high-stakes settings.
- Tool/product/workflow: “Post-Training Safety Card” templates; auditing protocols that verify compute disclosures and diversity safeguards.
- Assumptions/dependencies: Community adoption; access to logs; consensus on diversity and difficulty metrics.
- Robotics and sim-to-real skill acquisition (robotics, manufacturing)
- What to do: Use tokenized, structured action spaces with verifiable simulator rewards to train planning policies that are later fine-tuned with real-world RL; plan pretraining vs RL in sim using the joint law.
- Tool/product/workflow: “Reasoning-in-Actions” pipelines where robots generate and score plan traces before executing; sim curricula with difficulty bins.
- Assumptions/dependencies: High-fidelity simulators, reliable sim-to-real transfer; stepwise verification of subgoals; larger action spaces and partial observability complicate transfer of the law.
- Decision optimization in energy, logistics, and healthcare operations (energy, supply chain, healthcare ops)
- What to do: Frame tasks with simulators/validators (grid dispatch, routing/scheduling, coding/billing with checkers) and use the law to balance offline pretraining on logs with online RL against simulators.
- Tool/product/workflow: “Ops-RL Planner” that predicts ROI of additional logs vs simulator runs and sets RL fractions accordingly.
- Assumptions/dependencies: Simulator fidelity and reward alignment; ethical/operational constraints on online exploration; careful generalization beyond chess/math needed.
- Model documentation and governance of compute spend (policy, ESG/finance)
- What to do: Disclose not only total compute, but its split across stages and the expected marginal value (slope B) at the time of RL initiation; tie funding or carbon reporting to compute-efficient allocations.
- Tool/product/workflow: Compute-efficiency dashboards for investors/regulators; carbon/CapEx planning that incorporates shifting RL fractions with scale.
- Assumptions/dependencies: Trusted compute accounting (FLOPs), shared baselines for what counts as RL compute, and independent verification.
- Adaptive curricula that deepen search (academia, education)
- What to do: The paper shows RL broadens search more than it deepens it; design SFT/RL curricula and datasets that explicitly reward deeper, longer-horizon reasoning while retaining verifiable feedback.
- Tool/product/workflow: Difficulty-weighted data pipelines that up-weight long-horizon continuations; step-penalized rewards to encourage efficient deeper exploration.
- Assumptions/dependencies: Reliable measurement of search depth and move/step quality; careful reward shaping to avoid degenerate behavior.
Notes on Assumptions and Dependencies Across Applications
- Verifiable rewards: The strongest results rely on environments where step- or episode-level correctness is explicitly checkable (engines, unit tests, provers, simulators). Applications without such verifiers will need alternative reward shaping and may not exhibit the same scaling behavior.
- Domain calibration: The joint scaling law was established in chess and qualitatively replicated in a math setup with a 1B model; applying it elsewhere requires re-fitting and verification to avoid over-generalization.
- Metric sensitivity: Gains concentrate in pass@1; pass@k and diversity can stagnate or regress under RL unless explicitly preserved.
- Compute accounting: The recommendations assume FLOP-based accounting; wall-clock costs can diverge materially across stages and systems.
- Saturation effects: The log-linear fit describes the early-to-mid RL regime before saturation; near plateaus, ceiling-aware models (e.g., sigmoids) and longer runs are required.
Glossary
- AlphaZero: A reinforcement learning system that mastered games like chess and Go via self-play without human expert data. "and exemplified by AlphaZero, which famously removed the imitation cold-start used by earlier AlphaGo and learned stronger policies from self-play alone"
- autoregressive policy: A model that predicts the next token conditioned on previous tokens, producing a distribution over sequences. "we train an autoregressive policy over tokenized games using the standard next-token prediction objective."
- beam search: A heuristic search strategy that keeps a fixed number of top candidates at each step to explore likely sequences. "such as MCTS and beam search"
- Chain-of-Thought (CoT): Explicit intermediate reasoning steps generated by a model before producing a final answer. "Motivated by prior work on CoT generation"
- Chinchilla law: A scaling law describing compute-optimal tradeoffs between model size and training tokens to minimize loss. "A functional-form fit of the Chinchilla law is provided in Appendix~\ref{sec:appendix_chichilla_fit}."
- compute-optimal frontier: The best achievable performance for each compute budget when optimally allocating resources across stages. "We trace a compute-optimal frontier, and find that the optimal allocation shifts toward a larger RL fraction as total compute grows"
- en passant: A special chess capture that can be made immediately after a pawn advances two squares. "such as promotion, castling, en passant, check, or checkmate."
- Elo rating: A numeric score representing a chess player’s strength, used to filter or stratify data. "axes such as player Elo"
- FLOPs: Floating point operations; a unit measuring computational cost. "We sweep 11 pretraining compute budgets from to FLOPs"
- Group Relative Policy Optimization (GRPO): A policy-gradient RL algorithm that leverages relative comparisons within groups of samples. "We optimize the policy with Group Relative Policy Optimization (GRPO)"
- inference-time search: Search procedures applied during model inference (not training) to improve decision quality. "inference-time search algorithms"
- IsoFLOP curves: Performance curves comparing models under equal compute budgets to study scaling behavior. "we report IsoFLOP curves for validation loss on held-out human games"
- leave-one-out validation: A validation method where each run is predicted using a model fit to all other runs. "Leave-one-out validation on our existing runs shows that the fitted parameterization predicts held-out RL trajectories well"
- Lichess: An online chess platform and database used as a source for games and puzzles. "We collect game trajectories from Lichess"
- Monte Carlo Tree Search (MCTS): A search algorithm that uses random simulations to evaluate actions in a game tree. "such as MCTS and beam search"
- Pareto frontier: The set of non-dominated tradeoffs where improving one metric would worsen another. "Black curves mark the Pareto frontier."
- pass@k: The probability that at least one of k sampled outputs is correct; a Best-of-k accuracy metric. "pass@$1$ and pass@$16$"
- power transformation: Raising probabilities to a power to sharpen or flatten a distribution. "we test whether the RL policy is a power transformation of the SFT policy,"
- pretrained prior: The capabilities and distributions learned during pretraining that initialize post-training. "One emphasizes the pretrained prior"
- SAN (Standard Algebraic Notation): A compact human-readable chess move notation. "Drawing on the SAN and UCI conventions"
- self-play: Training where an agent plays against itself to generate experience. "learned stronger policies from self-play alone"
- sigmoid RL scaling law: A model where performance as a function of RL compute follows a sigmoidal curve with a saturation ceiling. "proposes an RL scaling law that models the performance of a fixed model as a sigmoid function of RL compute"
- supervised fine-tuning (SFT): Post-training that adjusts a pretrained model using labeled examples to align with target tasks. "typically supervised fine-tuning (SFT) and reinforcement learning (RL) with verifiable rewards"
- temperature scaling: A method to adjust the sharpness of a probability distribution by dividing logits by a temperature parameter. "RL is not well explained by a uniform temperature scaling of SFT."
- tokens per parameter: A scaling ratio measuring training data size relative to model size. "tokens per parameter "
- UCI (Universal Chess Interface): A protocol and move-notation style used by chess engines. "Drawing on the SAN and UCI conventions"
- verifiable rewards: Rewards that can be deterministically computed from ground-truth, enabling precise RL signals. "RL with verifiable rewards"
Collections
Sign up for free to add this paper to one or more collections.