Vela: Selecting Tasks and Trajectories by Difficulty

Why People Wanted It

A large collection of tasks is not automatically a useful training set. If a task is trivial for a model, its answer may teach little; if the task is far beyond the available generator, its generated trajectory may be poor supervision. Vela treats task selection and answer selection as separate decisions: first ask whether a task is worth training on, then ask whether a generated answer is strong enough to keep.

The Core Move

Estimate each task's difficulty from several model responses, keep tasks in an intermediate score band, and accept a generated trajectory only when it beats that task's baseline score.

For task $t$, let $s_{t,j}$ be the scorer's score for response $j$. The difficulty estimate is the mean response score:

$$\bar{s}_t = \frac{1}{4}\sum_{j=1}^{4}s_{t,j}.$$

In words, four scored attempts become one estimate of how difficult the task is for the filtering model.

Why the Score Band Selects Intermediate Tasks

Now the version for readers who want more of the machinery: the filtering model produces four responses with thinking disabled, and the scorer evaluates each response. Vela retains tasks whose mean score lies in $[0.2, 0.8]$. The lower cutoff removes tasks where these attempts perform poorly on average; the upper cutoff removes tasks that are already handled well on average. The band is a practical proxy for “neither too hard nor already solved,” not a claim that every retained task has identical difficulty.

The threshold is applied to the mean, not to every individual response. So a task can remain even when its four attempts vary, provided their average falls inside the band. What does this estimate capture when responses are inconsistent? It captures average performance, not uncertainty or disagreement.

Why Trajectory Acceptance Uses the Task's Own Baseline

Here is the part that gets technical: each generation model creates four trajectories for a retained task, but only the highest-scoring one is considered. If that best score is $g_t$, the trajectory is accepted only when $g_t > \bar{s}_t$, where $\bar{s}_t$ is the difficulty-filtering mean for that task. In words, generation must beat the baseline established by the filtering attempts; otherwise, that model contributes no trajectory for that task.

This is a relative gate, not a universal quality threshold. A retained task's generated answer is judged against its own estimated baseline, so acceptance depends on both the generation result and the earlier task score. Why use the best of four and then compare it to the baseline, rather than keeping every attempt? The rule favors a strong candidate without automatically treating all sampled answers as training targets.

Why Vela-Instruct and Vela-RFT Have Different Sources

Now for the construction detail: the same filtering and acceptance logic feeds two corpora, but their generation models differ. Qwen3.8-2.4T-A95B at the xhigh thinking level generates Vela-Instruct trajectories. Qwen3.6-35B-A3B with thinking enabled generates Vela-RFT trajectories, so Vela-RFT is self-generated by that model.

For Vela-Instruct, the joint task and trajectory filters retain approximately 75,000 of 100,000 candidate tasks, with one training trajectory per retained task. Vela-RFT is smaller, with 9,375 training samples. Those counts describe these constructions; they are not a general guarantee about how many examples a similar pipeline will keep. What changes when the generator is also the model being trained? That is the self-generation choice specific to Vela-RFT.

Minimal Causal Code

This loop makes the two gates visible. score is a placeholder for the task scorer, and the data objects stand in for task prompts and generated responses.

kept = []

for task in candidate_tasks:
    baseline_scores = [score(task, response) for response in filter_responses(task)]
    difficulty = sum(baseline_scores) / len(baseline_scores)

    if not (0.2 <= difficulty <= 0.8):
        continue

    trajectories = generate_four(task)
    best = max(trajectories, key=lambda item: score(task, item))
    best_score = score(task, best)

    if best_score > difficulty:
        kept.append((task, best))

What You Gain, and What You Lose

The two-stage gate avoids treating every available task and every generated answer as equally useful: task filtering targets an intermediate performance range, while trajectory acceptance requires a candidate to outperform the task's filtering mean. The construction also gives a clear distinction between Vela-Instruct's external generator and Vela-RFT's self-generation.

The tradeoff is dependence on the scorer and the sampled responses. Four attempts summarized by a mean can miss response variability, and the fixed score band makes retention sensitive to how the scorer's scale behaves. The trajectory rule can also reject a task for a particular generator even after the task itself passed filtering. You gain a controlled selection rule; you do not get a guarantee that every accepted trajectory is correct or that every rejected task is unlearnable.

Quiz

What are the two distinct decisions in Vela's data-selection process?

Keep every task with one high-scoring response, then include all four generated trajectories.

Select tasks by generator identity, then accept trajectories using a single universal quality threshold.

Keep only tasks where all filtering responses have exactly the same score.

Keep tasks with intermediate mean response scores, then accept a generated trajectory only if its best score exceeds the task's mean.

$ check