Papers
Topics
Authors
Recent
Search
2000 character limit reached

Rufus-Air: An Open LLM Post-Training Recipe

Published 24 Sep 2026 in cs.CL, cs.AI, and cs.LG | (2609.29421v1)

Abstract: Rufus-Air is an open and reproducible post-training recipe on GLM-4.5-Air-Base (106B-A12B), organized as a serial pipeline of eight stages: SFT, Reasoning RL, Coding RL, Instruction-Following RL, General Agent, Coding Agent, Search Agent, and RLHF. We document the data, reward design, infrastructure, stage order, and stagewise results needed to reproduce the recipe. Stages progress from basic to advanced capabilities and from hard, verifiable rewards to softer judge-based signals. Training builds on open-source components and public data, much of it used as released, without new human annotation or an in-house distillation teacher. Our main findings are that (i) diverse, high-quality SFT establishes a strong capability floor; (ii) difficulty filtering keeps RL prompts within a productive learning range; (iii) reward reliability provides a practical principle for ordering stages; and (iv) infrastructure and engineering choices are part of the recipe, not just an implementation detail. Rufus-Air improves over the official GLM-4.5-Air post-trained release and is competitive with similarly sized open models.

Summary

  • The paper presents an eight-stage post-training recipe for a 106B-parameter, 12B-active Mixture-of-Experts (MoE) model, improving instruction following, tool use, and browsing via supervised fine-tuning (SFT), verifiable-reward RL, agentic RL, and RLHF.
  • The model’s supervised fine-tuning stage, consisting of 9.01 million examples and 27.04 billion loss-contributing tokens, establishes a strong baseline that improves instruction following by 24.15 points on IFBench, and tool use tasks by 6.63 points on AIME 2025.
  • The instruction-following RL (IF RL) stage, incorporated into the training pipeline, enhanced the model's performance on Multi-challenge by 24.7 points and on AdvancedIF by 17.4 points, indicating significant improvements in preserving constraints and formatting quality

Rufus-Air presents a reproducible post-training recipe for a 106B-parameter, 12B-active Mixture-of-Experts model initialized from GLM-4.5-Air-Base. Its central contribution is not a new policy-gradient objective or a single specialized dataset, but an unusually complete account of how supervised fine-tuning, verifiable-reward RL, agentic RL, RLHF, and infrastructure interact in a serial production pipeline (2609.29421). The resulting checkpoint is evaluated against same-base and similarly sized open-weight models, with the strongest improvements concentrated in instruction following, tool use, browsing, and software-engineering tasks.

Recipe design and central claims

The pipeline consists of eight sequential stages:

SFT→Reasoning RL→Coding RL→IF RL→General Agent→Coding Agent→Search Agent→RLHF.\text{SFT} \rightarrow \text{Reasoning RL} \rightarrow \text{Coding RL} \rightarrow \text{IF RL} \rightarrow \text{General Agent} \rightarrow \text{Coding Agent} \rightarrow \text{Search Agent} \rightarrow \text{RLHF}.

Figure 1

Figure 1: Rufus-Air’s serial post-training pipeline from GLM-4.5-Air-Base to the final Rufus-Air checkpoint.

The ordering is motivated by two considerations. Capability development proceeds from broad model competence to increasingly specialized forms of interaction. Reward reliability proceeds in the opposite direction: deterministic verifiers are used before rule-based and LLM-based judges, and the most gameable learned reward—the RLHF reward model—is applied last. The paper is explicit that this is a practical ordering principle rather than a demonstrated optimum. Later stages update the same parameters and therefore can alter earlier capabilities; the reported stagewise comparisons are intended to establish local effects rather than prove that the global order is uniquely correct.

The paper advances four main claims. First, SFT establishes a substantive capability floor rather than merely initializing RL. Second, difficulty filtering creates an automatic curriculum by retaining prompts that are neither already solved nor entirely outside the current policy’s competence. Third, reward reliability should influence stage order because optimization pressure is more dangerous when the reward can be gamed. Fourth, rollout fidelity, router alignment, sandbox reliability, and environment orchestration are part of the algorithmic recipe.

Supervised fine-tuning as the capability floor

The SFT stage uses 9.01 million examples, 44.5 billion raw tokens, and 27.04 billion loss-contributing assistant tokens. The data combine general chat, STEM, mathematics, code, general-agent, and coding-agent trajectories. The distinction between sample share and token share is consequential: General Agent contributes 39.6% of examples but only 14.2% of training tokens, whereas Math and Coding Agent together constitute 18.8% of examples but 49.1% of loss-contributing tokens.

Figure 2

Figure 2: SFT composition by capability category, showing the divergence between sample share and training-token share.

The mixture contains 17 public datasets and no Rufus-Air-generated response regeneration or newly commissioned human annotation. Many released datasets nevertheless contain upstream model-generated trajectories, including outputs from DeepSeek-R1, QwQ-32B, GPT-OSS-120B, Qwen3, and other models. The paper carefully distinguishes these upstream dependencies from in-house distillation.

Preprocessing normalizes heterogeneous sources into a role-aware, multi-turn schema with explicit loss masks. System messages, user turns, and tool observations are retained as context but excluded from the loss. Interleaved reasoning and tool-use trajectories are segmented so that completed thought–action–observation chains form coherent supervision units. The production chat template is applied before length filtering, with a 120K-token sample cap and a 128K-token packed training context.

Decontamination combines sequential 8-gram overlap screening, exhaustive phrase matching for mathematical benchmarks, dense retrieval, and manual review. The procedure removes 4,187 SFT instances, including 68 confirmed contaminated benchmark–training pairs and 58 unique samples from the additional mathematics and knowledge checks. The authors acknowledge that n-gram and embedding filters cannot eliminate all semantic leakage, but the procedure materially improves the credibility of the reported evaluations.

The production SFT run uses three epochs on 512 H200 GPUs. The learning rate warms up to 5×10−55 \times 10^{-5} and decays toward 5×10−65 \times 10^{-6}. Training loss continues to decrease across epochs, but held-out benchmark scores plateau during the first epoch. The pipeline therefore selects checkpoint 3799 rather than the final low-loss checkpoint.

Figure 3

Figure 3: SFT loss continues declining after held-out capability scores have largely plateaued, motivating selection of an intermediate checkpoint.

The SFT checkpoint already surpasses the public GLM-4.5-Air post-trained release on IFEval by 5.33 points, IFBench by 24.15 points, AIME 2025 by 6.63 points, and AIME 2026 by 3.50 points. It trails on GPQA by 5.72 points. This result supports the paper’s strongest SFT claim: a carefully composed supervised mixture can produce a broadly capable policy before RL, while also revealing domain-specific deficits for subsequent optimization.

Benchmark GLM-4.5-Air Rufus-Air SFT Change
IFEval 83.00 88.33 +5.33
IFBench 33.60 57.75 +24.15
GPQA 73.90 68.18 -5.72
AIME 2025 84.20 90.83 +6.63
AIME 2026 86.50 90.00 +3.50

Verifiable-reward RL and learnability filtering

Reasoning RL targets mathematics, scientific question answering, and algorithmic puzzles. Its prompt set contains 121,161 tasks, with mathematics accounting for 47.7% of prompts, science for 35.7%, and puzzles for 16.7%. Puzzles contribute 55.5% of prompt tokens because their serialized states and rule specifications are substantially longer.

The reward functions are deterministic: Math-Verify for canonical mathematical answers, generated Python checkers for puzzles, and fuzzy string matching for science answers. A teacher-solvability filter removes prompts that GPT-OSS-120B cannot solve, while a learnability filter excludes prompts solved by the current policy more than 80% of the time or never solved in sampled rollouts. During training, dynamic sampling retains groups whose mean reward lies in (0,0.8](0, 0.8]. This creates an online difficulty frontier: as the policy improves, previously unlearnable prompts can enter the productive band.

The stage uses GSPO with sequence-level clipping, truncated importance sampling, large rollout groups, and a length penalty relative to the shortest correct sample. Relative to SFT, GPQA rises from 68.18 to 73.50, a gain of 5.32 points. AIME 2025 and AIME 2026 decline by 2.81 and 2.60 points respectively. The paper treats these changes as acceptable guardrail variation because each AIME evaluation contains only 30 problems and the observed differences are smaller than one problem’s effective contribution under the stated evaluation procedure. The result supports a narrower claim: the verifier-based stage improved the targeted scientific-knowledge metric, but it did not uniformly improve all reasoning benchmarks.

Coding RL then trains against executable Python tests. The 29,405-problem mixture combines functional and stdin/stdout tasks, with EvolveCoder supplying 50.1% of the problems. Teacher solvability filtering and a warm-up drop-all-pass screen remove problems that provide little group-relative signal. Test subsampling is deterministic, preventing reward drift across rollouts.

Figure 4

Figure 4: Coding RL reward and LiveCodeBench performance improve after the response budget is extended from 64K to 128K tokens.

The response budget initially produces truncation rates between 11% and 28%. After extending the limit from 64K to 128K tokens, truncation falls below 0.1%, and the raw reward resumes increasing. LiveCodeBench v6 pass@1 rises from 68.6 to a peak of 75.9, a 7.3-point improvement, while pass@8 increases by only 2.3 points. This divergence suggests that the stage primarily improves first-sample reliability rather than merely increasing the probability that at least one of many samples succeeds. It also demonstrates that rollout truncation is not merely an infrastructure statistic: because truncated samples are loss-masked, it directly controls the amount of useful gradient entering the update.

Instruction-following RL

Instruction-following RL jointly optimizes two datasets: 14,000 single-turn prompts with programmatically verifiable constraints and approximately 13,000 adversarial multi-turn conversations. The constraints cover formatting, length, structural requirements, lexical conditions, instruction hierarchy, and persistence of user requirements across turns.

Each instance receives a binary reward only when all required rubrics are satisfied. The paper makes an important distinction between necessary and optional rubrics. Optional desiderata are excluded because they add reward noise and encourage the model to produce unnecessarily long responses. When the authors experimentally attach many optional rubrics, the policy develops a pronounced length bias; when rubrics express only necessary conditions, final responses become shorter while task performance improves.

The stage produces some of the largest targeted gains in the pipeline:

Benchmark Coding RL + IF RL Change
IFEval 90.5 94.5 +4.0
IFBench 63.8 77.8 +14.0
Multi-challenge 31.1 55.8 +24.7
AdvancedIF 45.5 62.9 +17.4
GPQA 67.9 71.1 +3.2
AIME 2025 87.6 86.4 -1.2

The 24.7-point improvement on Multi-challenge is particularly strong because it targets multi-turn instruction retention rather than isolated formatting. The concurrent increase on GPQA and near-preservation of AIME indicate that the stage did not impose a substantial reasoning trade-off under these measurements. The paper attributes the effectiveness of reasoning-first ordering partly to prerequisite structure: complex instruction following requires reasoning over constraints, and the Reasoning RL checkpoint supplies that behavior before IF optimization.

Figure 5

Figure 5: Instruction-following RL reward rises while final response length decreases under necessary-condition rubrics.

Agentic reinforcement learning

The three agent stages use distinct environments but a common infrastructure abstraction. General Agent training uses approximately 2,000 filtered tasks from AgentWorldModel, with MCP tools operating over stateful synthetic databases. The terminal and search stages use execution-based and web-based environments respectively.

General Agent training improves MCP-Atlas by 7.80 points and Tau2-Retail by 9.80 points relative to the IF RL checkpoint. AIME 2026, IFEval, GPQA, and LiveCodeBench remain stable or improve modestly.

Figure 6

Figure 6: General Agent training increases held-out tool-use performance while trajectories become longer.

The result is consistent with transfer from synthetic MCP environments to external tool-use benchmarks, although the evaluation cannot isolate which environment properties produce that transfer. The authors interpret the result as evidence that stateful tool orchestration—planning, tool-call formation, error recovery, and state tracking—can be learned from synthetic environments.

Coding Agent training operates in Harbor-format terminal sandboxes using a single shell-execution tool. Rewards are binary and based on task-specific tests. Relative to General Agent, Terminal-Bench 2.1 increases from 38.76 to 40.17 and SWE-bench Verified from 65.60 to 67.80. These are modest gains, and the paper explicitly states that the stage ended because of compute constraints rather than convergence.

The later shipped checkpoint reports Terminal-Bench 2.1 at 42.7 but SWE-bench Verified at 65.6, equal to the Coding Agent stage’s starting value. Because the intervening Search Agent and RLHF stages were not individually evaluated on these benchmarks, the final differences cannot be attributed to a particular later stage.

Search Agent training uses approximately 2,200 questions selected from MiroVerse. The filtering strategy is unusually aggressive: questions answerable without tools are removed, and questions with zero or eight successes among eight initial tool-enabled rollouts are also excluded. The final set therefore concentrates on tasks that are difficult but demonstrably solvable.

The reward is a continuous LLM-judge score, gated on at least two successful tool calls and reduced for malformed calls. The authors remove a format bonus after observing that the policy exploited it through tool-free guesses. A mean-only group advantage is used instead of standard-deviation normalization. In an ablation, mean-only advantages produce held-out scores from 55.8 to 64.8, compared with 49.7 to 58.7 for normalized advantages. The authors argue that standard deviation normalization removes the magnitude of partial-credit differences and amplifies grading noise, particularly in groups containing a single apparent success.

Figure 7

Figure 7: Search Agent reward and held-out success increase as the policy learns more effective tool-use patterns.

Search Agent improves BrowseComp by 3.0 points, Seal-0 by 5.4 points, and HLE-Verified by 3.4 points. The improvement transfers to an evaluation environment with a different search backend. However, tool-use analysis shows that additional depth is not uniformly beneficial. On BrowseComp, trajectories exceeding roughly 50 iterations are predominantly failures, and budget exhaustion or context overflow is almost never associated with correctness. The policy’s late-stage increase in long successful searches therefore reflects selective deepening rather than an unconditional preference for longer trajectories.

RLHF and final benchmark position

RLHF is applied last using Skywork-Reward-V2-Qwen3-8B on filtered HH-RLHF prompts. Training uses only prompts; chosen and rejected responses are used for dataset analysis but not directly optimized. A linear length penalty is added to the reward-model score, and GRPO is used for on-policy updates.

The stage raises Arena-Hard v2 Hard Prompt from 83.06 to 89.05, a 5.99-point gain, and Creative Writing from 38.56 to 52.97, a 14.41-point gain.

Figure 8

Figure 8: RLHF improves held-out reward-model scores and Arena-Hard performance under a linear response-length penalty.

The Creative Writing improvement is substantial, but the final Rufus-Air score of 53.0 remains below GLM-4.5-Air’s 60.3 and Nemotron-3-Super’s 61.5. The paper therefore makes a deliberately limited claim: the selected reward model improves open-ended alignment metrics, but it does not establish that the resulting reward is well matched to stylistic quality. On other monitored metrics, stage-specific evaluations show changes of roughly one point or less, although the paper cautions that not all benchmark protocols are identical across the stagewise and headline evaluations.

Across the final comparison, Rufus-Air leads the official GLM-4.5-Air release on every reported benchmark except Arena-Hard v2 Creative Writing. Its headline results include:

Benchmark Rufus-Air
IFEval 95.4
IFBench 76.9
Multi-challenge 65.8
GPQA 75.6
AIME 2025 88.3
AIME 2026 86.7
LiveCodeBench v6 76.4
MCP-Atlas 45.3
BrowseComp 37.1
Seal-0 51.4
HLE-Verified 51.1
Terminal-Bench 2.1 42.7
SWE-bench Verified 65.6
Arena-Hard v2 HP 89.1
Arena-Hard v2 CW 53.0

Against Nemotron-3-Super, Rufus-Air is strongest on instruction following, search, MCP-Atlas, LiveCodeBench, and SWE-bench Verified; it is close on mathematics, science, and Terminal-Bench; and it trails on Creative Writing, Tau2-Airline, and slightly on Tau2-Retail. The paper appropriately qualifies cross-model comparisons because several external numbers use different judges, tools, user simulators, or inference-time context-management strategies.

Infrastructure as part of the method

Rufus-Air uses Rufus-Slime, built on Slime, Megatron-LM, and SGLang, together with Rufus-Gym for agentic environments. The infrastructure decisions are tightly coupled to the RL objectives.

The most important mechanism for the MoE model is Rollout Routing Replay, which reuses rollout-time expert assignments during the training forward pass. This reduces the routing discrepancy between FP8 inference and BF16 optimization. Rollouts use FP8-quantized SGLang engines, while parameter updates remain in BF16.

The agent environments preserve exact token trajectories through token-in/token-out execution. Rather than re-rendering and re-tokenizing the entire dialogue after every tool call, the environment appends sampled token IDs and associated log probabilities, masks, and expert assignments directly. This avoids retokenization drift, repeated chat-template application, and training on tool-call text that was repaired after sampling.

Coding trajectories run in Firecracker microVMs backed by a self-hosted E2B runtime. Sandboxes retain process and filesystem state across the full episode, are initialized from snapshots, and are destroyed after termination. Ray distributes CPU-heavy environment actors, tool execution, and reward computation across nodes. These details are not peripheral: the Coding Agent and Search Agent stages depend on long-horizon interactions whose throughput and fidelity determine whether the policy receives enough usable gradient.

Limitations and open questions

The evidence does not establish that the eight-stage order is optimal. The authors state that it reflects prior experiments, engineering constraints, and the desire to delay gameable rewards; they do not provide a factorial ordering study or a systematic comparison with parallel specialist training and checkpoint merging.

Stagewise attribution is also incomplete. No single benchmark suite is measured after every stage, and several values use different evaluation protocols. In particular, the Coding Agent stage is compute-limited rather than converged, and final changes in Terminal-Bench, SWE-bench, and Seal-0 cannot be assigned uniquely to later stages. The paper also reports discrepant intermediate values for some benchmarks, including GPQA and IFEval, arising from different evaluation runs.

The headline comparisons contain externally reported baselines obtained under heterogeneous harnesses. This is especially important for Tau2-Bench, where changing the simulated user model shifts results by as much as 23.7 points. Search evaluations also depend strongly on context management: disabling the scratchpad reduces BrowseComp performance by 10.7 points. These findings mean that the reported model rankings are informative only when benchmark versions, judges, simulators, tool backends, and context policies are aligned.

Finally, the search and RLHF rewards remain imperfect. Search training uses an LLM judge whose repeated scores can disagree, and the requirement for two successful tool calls does not rule out memorized answers with incidental tool use. RLHF optimizes a learned reward model that may not fully capture creative-writing quality. The open question is therefore not whether these stages improve their immediate metrics—they do—but how robustly those improvements track independently validated task quality under altered judges and environments.

Conclusion

Rufus-Air provides a detailed empirical account of post-training a large MoE checkpoint through SFT, verifiable-reward RL, instruction-following RL, agentic RL, and RLHF. Its strongest technical conclusions concern data and systems design: broad SFT establishes a strong initial policy; learnability filtering concentrates RL on informative prompts; deterministic rewards should precede softer objectives; and exact token fidelity, router alignment, sandbox execution, and distributed environment orchestration are necessary components of long-horizon RL.

The final model substantially improves instruction following and agentic capabilities relative to the official same-base release, including gains of 24.7 points on Multi-challenge, 9.8 points on Tau2-Retail, 5.4 points on Seal-0, 7.3 points on LiveCodeBench pass@1, and 14.4 points on Arena-Hard Creative Writing relative to the immediate RLHF initialization. The paper’s principal value is the reproducible integration of these choices, while its own results leave the optimal stage order, long-run convergence of agentic RL, and robustness of judge-based rewards as unresolved empirical questions (2609.29421).

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

1. What is this paper about?

This paper explains how the researchers built Rufus-Air, an open LLM that can:

  • Answer questions
  • Solve math and science problems
  • Write computer programs
  • Follow complicated instructions
  • Use tools
  • Search for information
  • Work as a software or research assistant

The model was not trained completely from the beginning. Instead, the researchers started with an existing open model called GLM-4.5-Air-Base and improved it through a series of training steps. This process is called post-training.

The main purpose of the paper is to give other researchers a detailed “recipe” for making a strong model using open tools, public data, and a manageable amount of computing power.

2. What questions are the researchers trying to answer?

The paper focuses on several practical questions:

  • How should a LLM be improved after its basic training is finished?
  • Which training steps should happen first, and which should happen later?
  • Does the model need lots of carefully chosen examples before reinforcement learning can work well?
  • How can researchers tell whether an answer is correct?
  • How can training avoid rewarding the model for producing long but unhelpful answers?
  • Can a model built with public resources perform as well as other models of a similar size?
  • What technical details are important for making the training stable and repeatable?

The researchers are especially interested in making their work reproducible. This means that another team should be able to follow the same instructions and get similar results.

3. How did they do the research?

The eight-step training recipe

The researchers improved the model in eight stages:

  1. Supervised fine-tuning (SFT)
  2. Reasoning reinforcement learning
  3. Coding reinforcement learning
  4. Instruction-following reinforcement learning
  5. General agent training
  6. Coding agent training
  7. Search agent training
  8. RLHF

Each stage starts with the model produced by the previous stage. This is similar to teaching a student one subject at a time: first basic skills, then more advanced skills that depend on those basics.

Stage 1: Supervised fine-tuning

In supervised fine-tuning, the model studies examples of good conversations and tries to imitate them. It is similar to giving a student answer sheets and showing them how good solutions are written.

The researchers used about 9 million examples from public datasets. These examples covered:

  • General conversations
  • Mathematics
  • Science
  • Programming
  • Tool use
  • Multi-step tasks

They also checked the data for errors and tried to remove examples that were too similar to test questions. This helped reduce the risk that the model would simply memorize the answers to its tests.

The model learned not only what to answer, but also how to format its answers. This was important because later training stages needed to understand its reasoning, code, and tool calls.

Stage 2: Reasoning reinforcement learning

Next, the model practiced mathematics, science, and puzzles using reinforcement learning.

Reinforcement learning is like training a dog with rewards. When the model gives a correct answer, it receives a positive score. When it gives a wrong answer, it receives little or no reward.

The researchers used automatic checkers to judge many answers:

  • A math checker compared the final answer with the correct answer.
  • A puzzle program checked whether the solution worked.
  • A science checker compared the response with an expected answer.

These automatic checkers are called verifiers. They are useful because they can judge answers quickly and consistently without needing a person to inspect every response.

The researchers also removed questions that were:

  • So easy that the model already solved them almost every time
  • So difficult that the model never solved them

This left questions in the “productive middle”—problems that were challenging but still possible. This is similar to giving a student exercises that are difficult enough to teach something, but not so difficult that the student has no chance of succeeding.

Stage 3: Coding reinforcement learning

For coding tasks, the model wrote Python programs. The researchers then ran those programs against tests.

A program received a reward if it passed the tests. This is like checking whether a student’s calculator program gives the correct answer for many different examples.

The researchers used different kinds of coding problems, including:

  • Writing individual functions
  • Reading input and producing output
  • Solving competitive programming problems
  • Using techniques such as sorting and dynamic programming

The coding problems were also filtered so that the model would focus on tasks that were not already too easy.

Later stages: Following instructions and using tools

The next stages taught the model to:

  • Follow detailed instructions
  • Remember instructions across multiple messages
  • Use tools in a general setting
  • Write and test code in a working environment
  • Search for information online

An agent is a model that can take several actions to complete a task, rather than simply writing one answer. For example, an agent might search for information, use a calculator, inspect a file, or run code before giving its final response.

Final stage: RLHF

The last stage used RLHF, or reinforcement learning from human feedback.

In this method, answers are judged by people or by systems designed to imitate human preferences. The model is encouraged to produce responses that are more useful, clear, safe, and natural.

This stage was placed at the end because human-like quality is harder to measure exactly than whether a math answer or computer program is correct. Softer judgments can sometimes be “gamed,” meaning the model may learn to look good to the judge without truly improving.

Technical training details

The researchers used open-source software and many graphics processors, or GPUs, to train the model. GPUs are powerful chips that can perform many calculations at the same time.

They also used special systems for:

  • Generating many model answers
  • Running programs safely in sandboxes
  • Checking rewards
  • Sending data efficiently between training and testing systems

The paper argues that these engineering details are not minor. They are part of the recipe because poor systems can make training slow, unstable, or unreliable.

4. What did they find?

The model improved across many abilities

The final Rufus-Air model generally performed better than the official GLM-4.5-Air post-trained model.

For example, Rufus-Air achieved:

  • 95.4% on IFEval, a test of following instructions exactly
  • 76.9% on IFBench, another instruction-following test
  • 76.4% on LiveCodeBench, a coding test
  • 65.6% on SWE-bench Verified, which tests software engineering
  • 37.1% on BrowseComp, a search and research test
  • 51.1% on HLE-Verified, a difficult research-question test

The model did not win every test. For example, it was weaker than some other models on creative writing and a few airline or retail tasks. This shows that improving one ability does not automatically make every ability better.

Supervised fine-tuning created a strong starting point

The researchers found that SFT was very important. Before reinforcement learning, the SFT model already:

  • Followed simple instructions better than the comparison model
  • Performed well on math tests
  • Understood useful response and tool-use formats

This meant that reinforcement learning could improve existing abilities instead of trying to teach basic skills from the beginning.

Difficulty filtering helped reinforcement learning

The researchers found that reinforcement learning worked best when the questions were carefully selected.

Questions that were already solved almost every time provided little new information. Questions that were never solved also provided little useful information. The most useful questions were those where the model sometimes succeeded and sometimes failed.

This filtering acted like an automatic curriculum. As the model improved, harder questions became suitable for training.

Simple rewards were useful

The early training stages used rewards that were easy to check:

  • Correct or incorrect math answers
  • Passing or failing code tests
  • Successful puzzle solutions

These rewards were more reliable than subjective judgments. The researchers therefore placed these stages earlier in the training process.

Later stages used more complicated judgments, such as whether an answer was helpful or whether an agent completed a realistic task. These stages came later because their rewards were less exact.

Some abilities improved more than others

The results showed that each stage mostly improved the skill it was designed to target.

For example:

  • Reasoning RL improved GPQA, a difficult science and knowledge test, from 68.2% to 73.5%.
  • Coding RL improved LiveCodeBench from about 67.9% to 75.9% during training.
  • Instruction-following RL improved IFEval from 90.5% to 94.5% at that stage.
  • Later agent stages improved coding, search, and tool-use tasks.

However, some scores went down slightly during certain stages. For instance, reasoning reinforcement learning improved GPQA but slightly lowered the AIME math scores. This shows that training a model is a balancing act: making it better at one task can sometimes affect another task.

5. Why are these results important?

The paper’s main contribution is not a completely new mathematical algorithm. Instead, it provides a detailed and practical guide for improving an open LLM.

Its most important lessons are:

  • Start with broad, high-quality examples. A strong foundation makes later learning much more effective.
  • Train in a sensible order. Begin with skills that have clear answers, then move toward complicated tasks and human judgments.
  • Choose appropriately difficult problems. Training should focus on tasks that are challenging but still learnable.
  • Use trustworthy rewards whenever possible. Automatic tests are usually more dependable than vague quality scores.
  • Pay attention to the computer systems used for training. Efficient rollouts, reliable sandboxes, and consistent formatting can strongly affect the final result.
  • Measure every stage carefully. A model may improve on one benchmark while becoming slightly worse on another.

Conclusion

Rufus-Air shows that a strong open LLM can be built through a carefully planned series of training stages. The researchers began with examples of good behavior, then used automatic rewards to improve reasoning and coding, followed by training for instruction following, tool use, searching, and human-like quality.

The research could help universities, companies, and independent developers build better LLMs without needing to keep their methods secret or rely entirely on private data and systems. It also gives future researchers a starting point for testing which parts of the recipe matter most.

The broader message is that building a capable AI model is not just about making it larger. It is also about choosing good training examples, giving useful feedback, arranging lessons in the right order, and building reliable systems around the model.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

  • The paper does not provide full ablations isolating the effects of the eight-stage serial pipeline, so the contribution of each stage cannot be separated from interactions caused by its position and inherited checkpoint.
  • The proposed stage-ordering principle—progressing from harder, verifiable rewards to softer, judge-based rewards—is supported mainly by experience rather than controlled comparisons with alternative orderings.
  • The effect of reversing or rearranging specific stages, especially Reasoning RL versus Instruction-Following RL, remains unresolved; the reported ordering was partly inherited from prior experiments.
  • The paper does not quantify how much later stages preserve, degrade, or overwrite capabilities acquired in earlier stages, beyond limited stage-specific benchmark comparisons.
  • There is no systematic comparison between serial training and joint or interleaved multi-task training across the same datasets and compute budget.
  • The benefits of the SFT data mixture are not disentangled from its total scale, token allocation, source quality, or category balance; mixture-weight ablations are absent.
  • The paper does not establish whether the reported SFT gains arise primarily from data diversity, long reasoning traces, tool-use trajectories, preprocessing, or the underlying GLM-4.5-Air base model.
  • The SFT checkpoint is selected using a small set of held-out benchmarks, but the robustness of this selection criterion across broader capability and safety measures is unknown.
  • The use of three SFT epochs is not compared with alternative numbers of epochs, making it unclear whether the early evaluation plateau generalizes to other data mixtures or downstream RL outcomes.
  • The paper does not assess the effects of excluding upstream model-generated traces from public datasets, leaving the contribution and risks of indirect distillation unresolved.
  • The contamination filters cannot reliably detect paraphrased, translated, structurally transformed, or semantically equivalent benchmark examples; the residual impact of such leakage is not quantified.
  • Decontamination is applied primarily relative to reported benchmarks, so contamination with unreported evaluations, future benchmark releases, or commonly used pretraining corpora remains uncertain.
  • The reasoning-task family labels are assigned using keyword heuristics, and the paper does not measure how misclassification affects data balance or stage performance.
  • The effectiveness of the teacher-based correctness filter is not compared against human validation, multiple-teacher agreement, or verifier-based solvability checks.
  • Reliance on GPT-OSS-120B for correctness and solvability filtering may introduce teacher-specific biases, but the sensitivity of the resulting dataset to the choice of teacher is unexplored.
  • The claim that difficulty filtering creates an automatic curriculum is not tested against static filtering, random sampling, explicit curricula, or alternative difficulty thresholds.
  • The selected productive-learning interval, particularly the group-average reward window (0,0.8](0, 0.8], is not systematically ablated.
  • It remains unclear whether retaining initially unsolved prompts in Coding RL, while dropping all-pass prompts, improves final performance relative to online filtering or bidirectional difficulty updates.
  • The reasoning RL stage lowers AIME performance while improving GPQA, but the paper does not determine whether this reflects capability trade-offs, benchmark variance, reward misalignment, distribution shift, or overfitting to GPQA-like data.
  • The reported AIME evaluation uses small sample sizes and exhibits substantial run-to-run variation; confidence intervals and statistical significance tests are not reported consistently for stagewise changes.
  • The paper does not evaluate whether reasoning RL improves broader scientific reasoning, transfer to novel mathematical domains, calibration, or robustness to adversarially designed problems.
  • Binary rewards for science QA rely on fuzzy string matching, whose false-positive and false-negative rates are not measured across different answer formats or domains.
  • The length penalty used in Reasoning RL is introduced as both a behavioral and efficiency control, but its coefficient, functional form, and effect on solution correctness are not ablated.
  • The paper does not establish whether reduced reasoning length reflects improved efficiency or undesirable suppression of valid intermediate reasoning.
  • The interaction between zero KL and entropy coefficients, sequence-level GSPO clipping, truncated importance sampling, and Rollout Routing Replay is not isolated experimentally.
  • The relative contributions of GSPO, Rollout Routing Replay, FP8 rollout inference, colocated training, and truncated importance sampling to stability and final performance remain unknown.
  • The paper does not report sensitivity to rollout temperature, group size, number of samples per prompt, optimizer steps per rollout, or response-length limits.
  • The effect of FP8 rollout quantization on reward estimates, policy updates, and final benchmark performance is not compared with higher-precision rollout inference.
  • The Coding RL evaluation and training rely heavily on Python and contest-style problems, leaving transfer to other programming languages, software-maintenance tasks, debugging, and less formal coding settings insufficiently examined.
  • Coding RL test subsampling selects at most 50 tests per problem; the probability that models exploit weaknesses in the selected subset rather than solve the underlying task is not quantified.
  • The paper acknowledges that rewritten or semantically equivalent contamination may evade coding decontamination, but does not evaluate the resulting leakage risk on LiveCodeBench.
  • The use of a deterministic test subset means reward diversity and robustness to hidden tests are not assessed during training.
  • The Coding RL stage does not include adversarial tests designed to detect hard-coded outputs, test-specific overfitting, unsafe code, excessive resource consumption, or sandbox exploitation.
  • The paper does not report the computational cost per solved problem or compare the efficiency of its coding-RL configuration with alternative rollout and verification budgets.
  • The provided text ends during the Coding RL section, leaving the data, reward design, training details, and empirical evidence for Instruction-Following RL, General Agent, Coding Agent, Search Agent, and RLHF incompletely specified.
  • Because the later agentic and RLHF stages are not fully documented in the provided paper text, their independent contributions, reward reliability, failure modes, and reproducibility cannot be evaluated.
  • The paper does not provide detailed human evaluation of helpfulness, factuality, harmlessness, or conversational quality beyond benchmark-based comparisons and judge-mediated metrics.
  • Reliance on LLM judges and preference rewards in later stages raises potential evaluator bias and reward-hacking concerns, but judge agreement, calibration, prompt sensitivity, and susceptibility to manipulation are not reported.
  • Arena-Hard Creative Writing is the only listed benchmark on which Rufus-Air underperforms the official GLM-4.5-Air release, but the paper does not investigate whether this reflects degradation in creativity, stylistic preference, verbosity, or judge mismatch.
  • Comparisons with public baselines are heterogeneous: only some models are evaluated under the authors’ harness, while other results are taken from external reports, limiting causal and apples-to-apples conclusions.
  • The paper does not report uncertainty estimates, repeated runs, or multiple random seeds for the complete pipeline, so reproducibility of the final gains is unknown.
  • No scaling analysis examines whether the recipe’s findings transfer to smaller, denser, larger, or architecturally different models.
  • The recipe is evaluated on one GLM-4.5-Air MoE base checkpoint, so the generality of its data filters, stage order, and infrastructure recommendations is unresolved.
  • The impact of the 106B-total/12B-active MoE architecture on post-training dynamics, routing stability, expert specialization, and catastrophic forgetting is not analyzed.
  • The paper does not measure inference-time costs, latency, memory use, or quality-efficiency trade-offs of the final model relative to the baselines.
  • Long-context and multi-turn performance are asserted as design goals, but systematic evaluations of context-length robustness, retrieval across long interactions, and error accumulation over extended tool-use trajectories are limited or absent.
  • The paper does not analyze safety risks introduced by agentic tool use, including prompt injection, unsafe tool calls, data exfiltration, sandbox escapes, or failures under adversarial environments.
  • The effects of post-training on factuality, uncertainty calibration, refusal behavior, and distributional robustness are not systematically evaluated.
  • The relationship between benchmark gains and real-world user outcomes remains unresolved, particularly for search, coding-agent, and general-agent tasks whose benchmark environments may not represent deployment conditions.
  • The paper reports engineering choices as part of the recipe but does not provide controlled evidence on how much each infrastructure component changes quality, stability, throughput, or cost.
  • The reproducibility claim is limited by incomplete disclosure of exact dataset versions, filtering code, prompt templates, checkpoint availability, random seeds, and some implementation-level details.
  • The paper does not specify how benchmark performance changes under alternative chat templates, tokenizer versions, tool schemas, or deployment-time decoding settings, despite emphasizing template consistency as important.
  • The long-term stability of the final model under continued training, domain adaptation, or repeated RL cycles is not studied.
  • It remains unclear whether the observed gains result from genuine capability improvements or from specialization and distribution matching to the curated training and evaluation tasks.

Practical Applications

Immediate Applications

  • Open-weight domain-specific assistant development — Software, enterprise AI
    • Organizations can use the released Rufus-Air checkpoint and recipe as a starting point for assistants that combine instruction following, reasoning, coding, search, and tool use.
    • A practical workflow is to begin with the SFT checkpoint for general chat and structured responses, then selectively reproduce later RL stages for the organization’s target domain.
    • Dependencies: access to suitable GPUs, compatibility with the GLM-4.5-Air tokenizer and native > chat format, high-quality domain data, and careful evaluation for contamination and hallucination. > > - Automated coding assistance and software maintenance — Software engineering > - The coding-RL methodology can support code-generation tools, unit-test repair, competitive-programming assistants, repository agents, and pull-request review systems. > - The paper’s execution-based reward design provides a directly usable workflow: generate code, run it in a sandbox against deterministic tests, assign binary success, and use only non-saturated problems for further optimization. > - Dependencies: secure sandboxing, reliable test suites, protection against destructive or malicious code, and tests that adequately cover intended behavior. Passing sampled tests does not guarantee production correctness. > > - Reproducible post-training laboratories — Academia and industrial research > - Research groups can reproduce or adapt the serial pipeline—SFT → reasoning RL → coding RL → instruction-following RL → agent training → RLHF—as a standardized experimental baseline. > - The reported use of open-source components, public datasets, staged checkpoints, and explicit reward designs makes it suitable for controlled comparisons of data curation, reward functions, curriculum filtering, and infrastructure. > - Dependencies: the paper documents many engineering choices but acknowledges limited full ablations; individual gains may therefore depend on the GLM-4.5-Air base model, data mixture, and hardware configuration. > > - Benchmark and data-quality auditing — Academia, model governance > - The paper’s layered decontamination workflow can be adopted to audit training corpora: sampled and exhaustive n-gram matching, embedding-based retrieval, manual review, and source-level provenance analysis. > - This can be integrated into dataset release pipelines and model evaluation governance to reduce benchmark leakage and improve the credibility of reported results. > - Dependencies: overlap filters cannot detect every paraphrase or semantically equivalent item; human review and continuously updated benchmark indexes remain necessary. > > - Automatic curriculum generation from model difficulty — Education and training systems > - The learnability filter can be used to select educational exercises or internal training tasks that are neither already mastered nor entirely infeasible. > - A tutoring system could estimate success rates, remove tasks with near-zero or near-perfect performance, and continually introduce items entering the productive learning range. > - Dependencies: binary correctness must be reliable, difficulty estimates must be representative of the learner, and the system must avoid reinforcing narrow benchmark-specific behavior. > > - Reliable tool-using assistants — Customer service, operations, productivity software > - The general-agent and instruction-following stages suggest workflows for assistants that call APIs, maintain multi-turn constraints, and execute structured business operations. > - Potential products include retail-support agents, airline-service assistants, telecom troubleshooters, and internal workflow copilots, corresponding to the paper’s Tau2-style domains. > - Dependencies: strict API schemas, authentication and authorization controls, action confirmation for consequential operations, and monitoring for incorrect or unauthorized tool calls. > > - Search and research assistance — Knowledge work and academia > - The search-agent methodology can be applied to systems that decompose questions, browse sources, compare evidence, and produce cited answers. > - A practical workflow would combine browser tools, source extraction, answer verification, and evaluation on research-oriented question sets. > - Dependencies: current and accessible web sources, citation verification, protection against prompt injection, and human review for high-stakes research or policy conclusions. > > - Reward and evaluation infrastructure as a reusable platform — ML operations > - The paper’s infrastructure choices—token-in/token-out rollouts, colocated FP8 inference and BF16 training, sandbox services, large batches, and rollout replay—can inform internal platforms for post-training models. > - Such a platform could expose reusable verifier interfaces for math, code, structured outputs, and tool trajectories. > - Dependencies: substantial engineering effort, distributed-training expertise, reliable scheduling and fault recovery, and secure isolation of externally generated code and tool calls. > > - Instruction-compliance testing for deployed assistants — Enterprise software and policy > - The strong improvements on IFEval, IFBench, and Multi-challenge indicate a practical use for strict instruction-following evaluations in pre-deployment testing. > - Organizations can test whether assistants preserve constraints across turns, obey output schemas, avoid prohibited content, and satisfy formatting requirements before integration into workflows. > - Dependencies: evaluation prompts must reflect real use, judges must be calibrated, and high benchmark scores should not be treated as evidence of general safety or factual reliability. > > - Everyday structured productivity assistance — Daily life > - A model trained with the paper’s capabilities could help users draft constrained emails, transform documents into specified formats, write small scripts, compare information sources, and execute low-risk multi-step tasks. > - The instruction-following gains are particularly relevant to tasks where users specify exact output structure or multiple simultaneous constraints. > - Dependencies: local privacy protections, transparent tool permissions, user confirmation before external actions, and safeguards against confident but incorrect reasoning. > > ## Long-Term Applications > > - Autonomous software engineering agents — Software development > - Combining coding-agent training, repository-level execution, search, and iterative testing could produce agents capable of diagnosing issues, modifying multi-file repositories, running tests, and preparing reviewable patches. > - A mature workflow would include task decomposition, repository search, code modification, test execution, rollback, and human approval. > - Dependencies: broader and more adversarial test coverage, long-horizon reliability, resistance to reward hacking, secure execution environments, and evaluation on real repositories rather than only curated benchmarks. > > - High-reliability research agents — Scientific research and academia > - The full pipeline could support agents that search literature, formulate hypotheses, write analysis code, verify calculations, and maintain an auditable chain of evidence. > - Verifiable rewards could govern computational subtasks, while judge-based or preference rewards could refine clarity and usefulness at the final stage. > - Dependencies: trustworthy scientific databases, domain-expert validation, reproducibility of experiments, citation correctness, and mechanisms for handling uncertainty rather than optimizing only for persuasive answers. > > - Healthcare decision-support systems — Healthcare > - The recipe’s combination of reasoning, instruction following, tool use, and evidence retrieval could inform clinical documentation assistants, medical literature search tools, and patient-education systems. > - Deterministic verifiers could be used for structured coding, dosage-format checks, guideline retrieval, or consistency checks, while clinicians review all consequential outputs. > - Dependencies: validated medical data, privacy and regulatory compliance, prospective clinical evaluation, calibrated uncertainty, and strict separation between decision support and autonomous medical decisions. > > - Education platforms with adaptive reasoning curricula — Education > - Online difficulty filtering could power systems that dynamically select mathematics, science, and programming problems based on a student’s current success band. > - The platform could use verifiable rewards for answers and code, track learning progression, and generate increasingly difficult tasks without requiring manual curriculum staging. > - Dependencies: pedagogically valid task generators, protection against teaching to the verifier, accessibility and fairness across learners, and validation that benchmark improvement corresponds to genuine understanding. > > - Robotics and embodied agents — Robotics > - The general-agent and coding-agent stages could be extended to robots that plan actions, call perception or control tools, execute programs, and recover from failed steps. > - Rule-based environment assertions could provide intermediate rewards for navigation, manipulation, or task completion, followed by preference-based optimization for natural interaction. > - Dependencies: realistic simulators, safe physical exploration, low-latency inference, robust perception, sim-to-real transfer, and reward functions that capture safety and physical constraints. > > - Industrial and energy operations assistants — Manufacturing and energy > - Tool-using agents could eventually monitor equipment, query operational databases, generate diagnostics, and recommend maintenance or scheduling actions. > - Deterministic verification is well suited to checking calculations, constraint satisfaction, and simulated operating plans before human approval. > - Dependencies: high-integrity sensor and process data, integration with legacy systems, cybersecurity, fail-safe execution, and extensive simulation before any autonomous control. > > - Financial operations and compliance automation — Finance > - The pipeline could support agents for document extraction, policy-constrained analysis, audit preparation, code generation for risk models, and retrieval of supporting evidence. > - Instruction-following benchmarks and structured verifiers could test compliance with reporting formats and internal rules. > - Dependencies: explainability, audit trails, data confidentiality, bias and fairness controls, regulatory approval, and prohibition of unsupervised high-impact financial decisions. > > - Self-improving post-training pipelines — AI infrastructure > - The online learnability filter suggests a scalable training loop in which prompts move into and out of the productive difficulty band as the policy improves. > - Future systems could automatically discover tasks, estimate solvability, select reliable verifiers, detect reward saturation, and allocate training to the most informative examples. > - Dependencies: robust automatic task validation, distribution-shift detection, safeguards against synthetic-data feedback loops, and independent evaluations to prevent optimization toward narrow internal metrics. > > - Hybrid verifier-and-judge alignment systems — General-purpose AI > - The paper’s ordering principle could lead to alignment pipelines that first optimize hard, auditable objectives and defer softer judge- or preference-based rewards until later. > - This may reduce exposure to reward hacking by allowing verifiable competence and stable output formats to precede open-ended preference optimization. > - Dependencies: the principle is supported mainly by training experience rather than exhaustive ablation; judge reliability, stage interference, and preservation of earlier capabilities require further study. > > - Open, domain-adaptable foundation models for smaller organizations — Public-sector and regional AI > - The recipe could lower the barrier for universities, public agencies, and smaller companies to adapt open models without training from scratch or relying on proprietary teachers. > - Organizations could publish domain-specific checkpoints, data provenance reports, reward definitions, and stagewise evaluations to improve transparency and reproducibility. > - Dependencies: the stated “small” compute footprint remains substantial—SFT uses 512 H200 GPUs, while later stages use up to 256 GPUs—so broader accessibility requires compression, parameter-efficient training, or smaller-model versions. > > - Policy frameworks for auditable model development — AI governance > - The paper supports policy requirements for documenting data provenance, contamination checks, reward mechanisms, infrastructure, stage order, and checkpoint-level evaluations. > - Such documentation could become part of model cards, procurement requirements, or regulatory submissions for high-capability systems. > - Dependencies: standardized reporting formats, independent audits, disclosure of sensitive information without exposing security vulnerabilities, and agreement on meaningful evaluation protocols.

Glossary

  • 8-gram overlap test: A contamination-detection method that compares sequences of eight words between training and evaluation data. “we screen the SFT mix against reported benchmarks with a word-level 8-gram overlap test”
  • AdamW: An adaptive optimization algorithm that combines Adam with decoupled weight decay. “We use AdamW~\cite{loshchilov2019adamw}”
  • Agentic stage: A post-training phase in which a model performs tasks through interactions with tools or environments. “The three agentic stages add tool use in their own environments”
  • Alignment: The process of training a model to behave according to desired human or system objectives. “Instruction following {paper_content} alignment”
  • Attention mask: A mechanism that controls which tokens contribute to a model’s computation or training loss. “with a per-message loss mask”
  • Automatic curriculum: A training strategy in which the data difficulty changes dynamically according to the model’s current abilities. “the filter acts as an automatic curriculum”
  • BF16: The bfloat16 numerical format, commonly used to reduce memory and computation costs during neural-network training. “BF16 training”
  • Canonicalized answer: An answer transformed into a standardized representation so equivalent responses can be compared reliably. “Math-Verify~\cite{mathverify2024} on canonicalized final answers for math”
  • Checkpoint: A saved snapshot of a model’s parameters at a particular point during training. “Rufus-Air names the checkpoint at the end of the pipeline”
  • Cosine schedule: A learning-rate schedule that changes the learning rate according to a cosine-shaped curve. “then follows a cosine schedule toward 5×10−65\times10^{-6}”
  • Cosine similarity: A measure of similarity between vectors based on the angle between them, often used for comparing embeddings. “manually check every training sample with high cosine similarity to any benchmark problem”
  • Decontamination: The removal of training examples that overlap with evaluation data to reduce benchmark contamination. “Our SFT data pipeline has three parts: composition, which fixes what goes into the mix; preprocessing, which converts every source into one supervision format; and decontamination, which screens the mix against the benchmarks we report.”
  • Dense retrieval: A search method that represents queries and documents as continuous vectors and retrieves semantically similar items. “dense retrieval with Llama-NV-Embed-Reasoning-3B~\cite{nvidia2026nvembedreasoning} embeddings”
  • Dynamic sampling: A training-data selection method that changes which examples are sampled according to current model performance. “following the dynamic-sampling idea in DAPO~\cite{dapo2025}”
  • Engine offload: The process of moving or switching model-serving components between computational resources to share hardware between inference and training. “alternating via engine offload”
  • Entropy coefficient: A reinforcement-learning hyperparameter controlling a model’s incentive to maintain diversity in its action distribution. “KL and entropy coefficients are zero.”
  • FP8: An 8-bit floating-point numerical format used to reduce the computational and memory cost of model inference or training. “colocated FP8-quantized SGLang engines”
  • Gradient clipping: A technique that limits the magnitude of gradients to improve training stability. “gradient clipping at 1.0”
  • Group-mean baseline: A reinforcement-learning baseline that uses the average reward within a group to reduce the variance of policy-gradient updates. “rollout groups with identical rewards provide no reward-driven policy-gradient signal under the group-mean baseline”
  • Group Sequence Policy Optimization (GSPO): A sequence-level policy-optimization algorithm designed for reinforcement learning of LLMs. “We use Group Sequence Policy Optimization (GSPO;~\cite{zheng2025gspo}) as the policy-gradient backbone”
  • Heterogeneous source shards: Data partitions originating from different datasets or formats. “Heterogeneous source shards are converted to one supervision format in three steps.”
  • Importance sampling: A statistical technique that reweights samples drawn from one distribution to estimate quantities under another distribution. “Off-policy correction across the two optimizer steps per rollout uses truncated importance sampling.”
  • Instruction-following RL: Reinforcement learning intended to improve a model’s ability to satisfy explicit user constraints and preserve instructions. “IF RL improves exact constraint following and the retention of instructions across turns.”
  • Interleaved thinking supervision: Training supervision in which reasoning steps, tool calls, and tool outputs are retained in their original conversational sequence. “(ii) interleaved thinking supervision: agent trajectories alternate between > reasoning, tool calls, and observations.”

    • KL coefficient: A reinforcement-learning hyperparameter that controls a penalty for divergence from a reference policy, measured using Kullback–Leibler divergence. “KL and entropy coefficients are zero.”

    • Learnability filter: A data-selection rule that retains examples neither already solved nor entirely beyond the current policy’s ability. “A learnability filter~\cite{foster2025lilo} then keeps prompts in the \emph{productive learning band} for the current policy”
    • Mixture-of-Experts (MoE): A neural-network architecture containing multiple expert subnetworks, with only a subset activated for each input. “a Mixture-of-Experts (MoE) model with 106B total and 12B active parameters”
    • Multi-turn schema: A structured representation of a conversation containing multiple alternating messages or interactions. “every source is mapped to a role-aware multi-turn schema with a per-message loss mask”
    • On-policy reinforcement learning: Reinforcement learning in which training data is generated by the current policy being optimized. “token-in/token-out rollouts for on-policy multi-turn RL”
    • Off-policy correction: An adjustment that accounts for training on samples generated by a policy different from the current policy. “Off-policy correction across the two optimizer steps per rollout uses truncated importance sampling.”
    • Policy gradient: A reinforcement-learning method that updates a policy directly using gradients of expected reward. “the policy-gradient backbone”
    • Post-training: The process of adapting a pretrained LLM through supervised fine-tuning, reinforcement learning, or preference optimization. “Rufus-Air is an open and reproducible post-training recipe”
    • Prompt-level strict evaluation: Evaluation that requires every specified condition in a prompt to be satisfied exactly. “IFEval and IFBench (prompt-level strict).”
    • Quantization: The representation of numerical model values with reduced precision to lower memory and computational requirements. “FP8-quantized SGLang engines”
    • Reward hacking: Behavior in which a model exploits weaknesses in a reward function instead of genuinely accomplishing the intended objective. “which limits how long training is exposed to reward hacking”
    • Reward model: A learned model that predicts the quality or preference score of a generated response. “reward model”
    • Rollout: A sampled model interaction or generated trajectory used to calculate reinforcement-learning rewards. “Each rollout samples 256 prompts”
    • Rollout Routing Replay: A method for replaying or routing generated training trajectories to improve the stability of reinforcement-learning updates. “large batches with Rollout Routing Replay~\cite{ma2025r3} for stable RL”
    • Sandboxed runtime: An isolated execution environment used to run generated code while limiting its access to the host system. “execute it in a sandboxed Python runtime against the problem's tests”
    • Sequence-level optimization: Optimization in which probabilities, clipping, or losses are computed over complete generated sequences rather than individual tokens. “GSPO defines the importance ratio and clipping at the sequence level”
    • Supervised fine-tuning (SFT): Training a pretrained model on examples containing desired input-output responses. “A strong, diverse SFT stage elicits much of the model's capability”
    • Truncated importance sampling: Importance sampling in which extreme weights are clipped or limited to reduce estimator variance. “Off-policy correction across the two optimizer steps per rollout uses truncated importance sampling.”
    • Verifier: A deterministic or learned mechanism that checks whether a model’s output satisfies a task’s requirements. “Deterministic verifiers deliver the rewards”
    • Verifiable rewards: Rewards computed from objectively checkable criteria, such as unit tests or exact answer matching. “Reasoning RL and Coding RL apply reinforcement learning with verifiable rewards (RLVR”
    • Warm-up samples: Initial samples generated to estimate task difficulty or model performance before the main training process. “before RL begins, we draw four warm-up samples per problem”
    • Weight decay: A regularization technique that discourages excessively large model parameters during optimization. “weight decay 0.1”

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Tweets

Sign up for free to view the 2 tweets with 121 likes about this paper.