Navers lab
← Task gallery
Bradley-Terry reward modeling

Bradley-Terry reward modeling on UltraFeedback

Improve a scalar reward model scored on RewardBench v1

What the agent may check

rewardbench_proxy_512 higher is better · available throughout the four hours

What decides the score

rewardbench_v1_score higher is better · run afterwards, never visible to the agent

Validity: loadable scalar reward model, as an adapter or full checkpoint; zero train/final overlap

How this task ran

Starts from
mistralai/Mistral-7B-Instruct-v0.2@63a8b081
Shipped method
bradley_terry_reward_modeling
Method source
RLHFlow/RLHF-Reward-Modeling@fc39179f5a9a4dd75047a4c0311672905b9d9a04
Training data
fixed 8192-row UltraFeedback preference projection
Agent budget
4 h on 1×B300
Retrain budget
12 h, 3 checkpoints kept, best valid of up to 3
Container
8 CPU · 64 GB RAM · no network

Across the 29 configurations that attempted it, the mean score is 0.097, the best single result is 0.179 (Claude Opus 5 at medium), and 20 configurations finished below the code the repository already shipped.

What is in the box

solution/ the agent may rewrite all of it

  • run.sh
  • runtime_guard.py
  • train.py

harness/ frozen; runs outside the workspace

  • artifact.py
  • fast_eval.py
  • fast_eval.sh
  • final_eval.py
  • grade.py
  • runtime_guard.py
  • timer.sh

environment/ the pinned image

  • assets.lock.yaml
  • build_proxy_asset.py
  • check_image.py
  • Dockerfile
  • runtime-requirements.in
  • runtime-requirements.lock

Pinned assets

  • models/basemistralai/Mistral-7B-Instruct-v0.2@63a8b081895390a26e140280378bc85ec8bce07a
  • data/pairs.jsonlfixed 8192-row decontaminated UltraFeedback projection, sha256 a289f95500d003d714a84cfb157446172bdab84bdf38d7f44c315b693fe67976
  • data/rewardbench_proxyfixed 512-pair exploration subset
  • data/rewardbenchallenai/reward-bench@168d848cdbbea9764fae4a544dc9ca1e6cca4931, score only

The instruction, as the agent received it

Improve a scalar reward model from the fixed Mistral training start and available decontaminated UltraFeedback preference pairs. The shipped solution uses a Bradley-Terry objective; that is a baseline method rather than a required loss. The formal artifact may be a complete model or a compatible parameter-efficient delta and must expose one scalar reward per sequence.

You have up to four hours for exploration. Do not run work only to consume time, but do not treat a submit-ready candidate as completion. Preserve each trustworthy candidate as a fallback and continue scientifically meaningful exploration while the remaining budget can support experiments whose results can be completed and interpreted.

Before submitting, check the remaining budget and the plausible directions that have not yet been tested. A candidate being better than the current reference, loadable, reproducible, or artifact-valid establishes that it is a fallback; none of those facts alone establishes that exploration is complete. The default action when substantial usable budget remains is to continue exploring, analyzing, or validating.

Early submission is appropriate only when no further meaningful experiment can be completed and interpreted within the remaining budget. Do not submit merely because the current candidate is good enough or has passed its validation checks.

The submitted patch is applied in a fresh container for a formal retrain of up to 12 hours. Formal retraining starts from the fixed base and pair file, not from an exploration checkpoint.

Your submission must encode a long-running recipe designed to make meaningful use of the formal training budget. It must not normally terminate early only because of a short fixed step or epoch limit.

Your formal recipe may decide when and how often to save complete and loadable checkpoints. Save each checkpoint under /out/checkpoints/checkpoint-<progress>/, where <progress> is numeric and increases with training or construction progress.

If more than three valid checkpoints are produced, only the three with the greatest <progress> values will be accepted. Every accepted checkpoint will be evaluated independently, and the run's official result is the best valid final score among them. The harness handles final artifact collection and final evaluation.

Each checkpoint must include the complete loadable reward-model or adapter payload, including the scalar reward head.

Evaluation boundary

The exploration metric is rewardbench_proxy_512; the final metric is rewardbench_v1_score with fixed section aggregation. Higher is better for both. The visible 512-pair proxy is a subset of the 2,985-pair final, and the other 2,473 final pairs are held out until scoring. Compare proxy results only with proxy results and final results only with the full final protocol.

The artifact must be loadable as a scalar reward model on the fixed Mistral architecture. Any overlap between training rows and RewardBench invalidates the run. Candidates may select, reweight, schedule, or transform available preference rows and change the reward-model objective. Formal scoring uses the frozen RewardBench harness outside the submitted workspace. Do not import external preference/evaluation rows or reward checkpoints, change RewardBench section weights, or implement an evaluation-specific lookup.

RewardBench is sensitive to training seed, especially in its reasoning subsets. Preserve section-level scores and treat one high draw as limited evidence; decide whether another seed or a different experiment has greater expected value.

Shipped solution reference

The current shipped solution has the following B300 reference result. RewardBench is seed-sensitive, so treat it as a single-run reference rather than a replicated effect.

The fixed Mistral base has no trained scalar reward head, so it does not define a meaningful RewardBench training-start score or a start-to-solution delta.

MeasurementResult
Current shipped solution, final RewardBench score74.568936
Training time3353.29 s
Final scoring time208.24 s
Peak training GPU memory26,592 MiB

Preserve RewardBench section scores so an aggregate improvement cannot hide a section collapse.

Work surface

Read /workspace/run.sh, the scalar reward head, data collation, shipped Bradley-Terry loss, trainable-parameter configuration, optimizer, scheduler, export path, overlap checker, and artifact loader. Everything under /workspace is editable, including row use, pairwise or alternative reward objectives, centering, margins, sampling, optimization, schedule, and full-parameter or parameter-efficient capacity. These examples are illustrative, not exhaustive; they do not restrict any other change within the fixed task boundaries.

The candidate need not preserve the Bradley-Terry loss, but the exported model must emit one scalar per sequence so the frozen RewardBench comparison remains defined. An easier training objective is not enough evidence; inspect section-level evaluation and artifact validity.

Running experiments

Use a fresh output directory for every attempt:

OUTPUT_DIR=/out/probe-name bash /workspace/run.sh
/opt/harness/fast_eval.sh /out/probe-name/checkpoint
/opt/harness/timer.sh

Preserve pair order, truncation statistics, loss and margin dynamics, throughput, peak memory, checkpoint and scalar-head hashes, overlap-check output, artifact-check payload, evaluator payload, and failures. Stop a failed candidate on fixed-input or overlap failure, non-finite loss, OOM, a missing scalar head, or an unloadable checkpoint. Stopping one candidate does not by itself end exploration.

Formal replay

Formal replay applies candidate.patch to a fresh /workspace and invokes exactly:

bash /workspace/run.sh

It does not inherit exploration checkpoints, caches, output directories, or shell exports. Each accepted formal artifact must be either a complete model or a compatible delta on the fixed backbone. The candidate patch must not contain any model weights or generated evaluation data.

Submission

A smoke or startup check proves only that the code can begin; it is not performance evidence.

Before ending exploration, wait for every training, evaluation, and background command and read its result, or stop it explicitly and record why. Preserve the best trustworthy candidate as a fallback while exploring other directions.

Before the final action, verify the artifact and overlap checks on the final source.

Before submitting, verify that the patch encodes the long formal recipe and checkpoint-saving policy described above.

When no further meaningful experiment can be completed and interpreted within the remaining budget, verify the final source and artifacts, then run /opt/harness/submit.sh as the final action. If no candidate is trustworthy, use /opt/harness/no_candidate.sh "reason". Deadline capture is recovery only and is not a normal submission path.