Skip to content
nano-gpt-data-curation

claude-opus-4-8

nano-gpt-data-curation — graded by the task's verifier against a measured baseline.

backend
modal
variant
claude claude-opus-4-8
metric
held-out multi-domain perplexity
actions
84
duration
1h 22m
recorded
2026-08-04

run iddclm-nano-curation__ohgR2nu

Score

reward
308.110
compare against every run on this task →

Summary

Done. All three deliverables are in place and verified against the official frozen pipeline.

Result

selectiondev held-out PPL
random baseline485.4
global quality/importance ranking + gate389.7
register-balanced (shipped)310.6

36% below the random baseline. Verified with the official pack_selection.py + train_nano.py (not just my fast packer, which I confirmed is byte-identical): the selection packs to exactly 12,000,000 tokens and scores 310.611. Validity guards pass — 22,284 ids, all unique, all in-range, 14.5M-token coverage.

Method (curate.py, self-contained & reproducible)

  1. Quality gate — cheap byte-level features drop non-English / symbol- or digit-heavy / repetitive / too-short junk (keeps 85%).
  2. Register model — k-means the disclosed target into K=4 registers (matching the 4 disclosed domains); each gets a unigram importance profile L_c = log p_c − log p_pool.
  3. Balanced retrieval — weighted round-robin fills the budget so the selection's register mixture matches the target's mixture ([0.10, 0.15, 0.50, 0.26]), instead of letting one loud register (news) dominate.

Why it works (the claim's observable, measured — not the final number)

I decomposed held-out loss by register. A global importance score over-serves the dominant register (reg2 PPL 280) but starves the others (reg3 PPL 459). Balancing collapses the bottleneck register — reg3: 459 → 178 — at ~zero cost to the saturated one (280 → 282), and that single fix accounts for essentially the entire 389.7 → 310.6 aggregate drop. The aggregate on a broad target is bottlenecked by its worst-covered register; matching the mixture beats taking the top.

Honest boundary noted in claim.md: balancing only helps where the pool has documents for a register — reg0 (encyclopedic-like) stays hard (~754) under both because the raw web pool has few strong matches.

A K sweep (3–20) was flat at 309–312 for K≥4; I chose the principled K=4. ~34 min of budget remain, but further tuning would chase noise-level differences and risk overfitting the disjoint official target, so I'm locking in the validated, well-understood result.

Transcript