Good article on evals from Anthropic:
Here is what I found insightful/interesting:
- They described the agent harness and eval harness to be distinct, however they are collapsed into one by verifiers and other frameworks
- They advise shipping reference solutions alongside tasks (not exhaustive) to prove solvability, but also to validate the grader
- 0% pass@k or similar with high k is usually a broken task
- Eval coverage is usually class-imbalanced and you must test when X behaviour should exist AND when it should not
- Read the transcripts!!!
- They split the purpose of the evals into capability/regression
Here is what I would tweak:
- They used 'likelihood' for pass@k and 'probability' for pass^k when defining. Both are probabilities over trial outcomes, I would use probabilities for both as the word change makes it look like a technical distinction.
- I would mention that both metrics assume i.i.d trials and also state that 1 − (1−p̂)^k is a biased estimator of pass@k
- I would put more emphasis on preventing gaming / cheating when designing evals
Worth a read:
https://t.co/CXrlFd261y
This is a good article on graders, however this is a subset of evaluations (dataset, harness, grader).
Lotte makes some great heuristics on creating graders:
- Prefer code evals to LLM judges, when possible
- Granularity over a broad test, because narrow judges are far easier to align
- Binary or categorical output over returning a scale, far easier to get consistency
- Label real cases before writing rubrics, as this prevents your idea of the eval from moving as you write it
- Validate LLM judges on labeled data, to test alignment
Wrote a piece on writing good evaluators, main take-aways:
- go for a code evaluator when you can
- don't rely on what the agent said it did, you need to actually verify
- calibrate your LLM as a judge against labeled data https://t.co/3wWoS5eDh6
@SergioPaniego The reward is hidden test pass fraction less penalties for bad behaviour. What is penalised? I wonder because of the 4B failure with tool-call spam. Did it exist before the collapse, or created because of it? Great work.
@paradite_ I think you are confusing the estimand and the estimator. pass@k is the population quantity (the probability that at least one of k trials succeeds). What we compute from the data is an estimator of it, and being estimated from data does not turn probability into a likelihood.
I watched @yacinelearning's video on RLVR environments for LLMs ft. @willccbb & @alexinexxx and I found Alexine's decomposition of envs very intuitive. RL envs are an MDP formally, but we can also think of envs more generally as just dataset, harness, grader. This makes it intuitive to both think about RL envs formally but to also understand why envs = evals functionally, as evals are just a dataset/harness/grader.
Her walkthrough of her environment Vision SR-1 using the verifiers framework is a great intro, and I would recommend watching the video:
https://t.co/Fl0vNXOKIE
@ShreyModi13 I think replicating prod envs is possible in a lot of cases by coding agents, but in practice a lot of the game is about reducing unnecessary complexity in the env for cost efficiency. And IMO that requires skill/expertise which I think will take longer to automate.