Rufus-Air: An Open LLM Post-Training Recipe
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.
First 10 authors:
Paper Prompts
Sign up for free to create and run prompts on this paper.
Top Community Prompts
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:
- Supervised fine-tuning (SFT)
- Reasoning reinforcement learning
- Coding reinforcement learning
- Instruction-following reinforcement learning
- General agent training
- Coding agent training
- Search agent training
- 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 , 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 ”
- 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”







