RL data 101: scoring
if the expected deliverable is verifiable only in the physical world (eg building a house), be sure to get kidnap and ransom insurance for your human-as-judge scorer
RL data 101: tasks
tasks have evolved over time. we started with preference pairs, where humans labeled right vs. wrong, A vs. B, and created simple demonstrations for SFT / pairs for DPO, these tasks aimed to engrave human taste into models. we then transitioned to more complex single-turn tasks. here, we turned to deterministic verifiers (RLVR) that are based on model rollouts. eventually, this evolved to multi-turn tasks with trajectories & deterministic + stochastic verifiers (LLMaaJ), which leads us to the current state of the data market.
general make up of a task: input prompt, set of tools, environment + any custom seeding for that task, and verifiers. terminal bench is a relatively gold-standard for a normal coding task.
ways i think about task creation (i'll do pitfalls later):
> usefulness
>> to labs:
>>> benchmark you're pegging the eval / data onto (Lab Y wants to hillclimb TBench, i make TBench-style data, that's immediately useful)
>>> capability you're attaching the eval to (Lab Y wants to become better at legal, i make legal red-lining data, that's immediately useful) --> this is harder to prove but potentially more valuable
>>> niche dataset that's impossible to get otherwise (real medical/company/session data), this is interesting especially pre-env creation, as raw data dumps
>> the above are general principles in thinking about usefulness, but you should also be picking apart the traces / trajectories. the clear path to making a good task (post-env gen) is to:
>>> you/LLM make the seed / think of the idea
>>> you/LLM draft the task prompt, verifiers, constraints etc
>>> run the task out, see score
>>> read the trajectory
>>> if score hard enough + real + fair + accurate = good task
>>> else: fix any issues in the task, regrade / re-rollout till you find it to be fair + accurate + a real task, difficulty comes last. a bad task that's hard is a bad task (net negative), a good task that's saturated is a good task (although worthless, net neutral).
the specific things i'd look for in a rollout trace:
> false positives
> false negatives
> brittle / too strict of requirements (sub-string checks are an easy example for this, exact wording, function names, etc)
>> a subset of this is naive verifiers. i.e. checking for very surface level reqs of a deep function, or not checking for large amounts of functionality or regressions (negative space criterion). this can lead to a model getting good at just the specific thing you want while regressing in surrounding functionality (i notice this a lot in early, less mature data recipes when im training my own models)
> unfair verifiers and/or impossible requirements
>> this can be an information issue, verifier issue, tool issue, or a prompt issue.
one of the key reasons for the hugging face incident was impossible eval prompts led to the models breaking out while trying to find the answer because they couldn't solve it (i.e. bad task creation, catalyzed by bad tasks in training too).
most of this is extremely hard for LLMs to do alone/autonomously, which is why really good engineers are still required for task creation.