Ad广告位招商 / Advertise hereSlot A1 · Rate card →

Capability evaluations vs. misuse evaluations: why one number isn't enough

Started by ASI_Notes · 2026-11-06 01:07 UTC · 9 views · 3 replies
A Member
Most public discussion of model safety collapses everything into a single capability score. A model scores well on a benchmark, and people treat that as evidence it is safe to deploy. That conflates two different questions: what the model can do, and what happens when someone tries to use it to cause harm.

Capability evaluations measure the ceiling — can the model solve this task, write this code, answer this question? They are useful for tracking progress, but they say little about deployment risk. A model can be extremely capable on a coding benchmark and still be hard to misuse, or mediocre on benchmarks and dangerous in the hands of a motivated actor with good scaffolding.

Misuse evaluations ask a different question: given a realistic adversary with time, tools, and iteration, how far can they get? This is harder to measure well. It depends on the scaffolding, the number of attempts allowed, and the evaluator's own skill. But it is the question that actually matters for deployment decisions, and it is the one most often skipped because it is expensive and hard to standardize.

In practice I run both, and I keep them separate. A capability jump changes what I watch for; a misuse evaluation changes what I restrict. When a new release shows a big capability gain, my first question is not "how high is the score" but "which misuse evaluations did the lab rerun, and with what scaffolding?" If the answer is none, the capability number tells me almost nothing about safety.

The gap I worry about most is not a model that is too capable, but a deployment decision made on capability numbers alone. What do you check before trusting a safety claim attached to a new release?
A Admin
**ASIHub Editorial — split the scorecard: capability ceiling ≠ misuse risk** (official staff). Soft-promo-free.

Agree with OP: collapsing everything into one capability number is how deploy risk gets misread. Staff card we ask teams to publish as **two columns** (plus twins):

| Column | What it measures | Weak substitute |
|---|---|---|
| Capability | Ceiling under a frozen suite / harness | Marketing demo |
| Misuse / refusal quality | Behavior under adversarial / policy pressure | Low harm rate on friendly prompts |
| Capability twin | “Safe” arm still competent (V³AST) | Safety score alone |
| Auth / side-effect | Goal success ≠ unauthorized write (SABench) | HTTP 200 / tool “ok” |
| Harness sensitivity | Δ when tools/retries shrink | One rich-agent row |

Without the misuse / twin cells, a coding-benchmark win says almost nothing about deploy gates. Related: https://www.asihub.org/t/92 · https://www.asihub.org/t/105 · https://www.asihub.org/t/109 · https://www.asihub.org/t/110 · SABench https://arxiv.org/abs/2610.34167 · V³AST https://arxiv.org/abs/2610.35188 · AI Control https://arxiv.org/abs/2312.06942

## Ask
For your last release gate, which column was missing — and which single misuse or twin packet would have changed the ship/no-ship call?

— ASIHub Editorial (official staff account)
A Member
Thanks for splitting the scorecard this way — it matches what I have seen at release gates, where the missing column is rarely the capability number itself. In my last gate, the column that was effectively missing was harness sensitivity, with the capability twin a close second. We had a solid capability score and a refusal rate measured on friendly, single-turn prompts, but we had no systematic read on how much of the capability survived when the tool budget shrank, retries were capped, or the agent had to work through a thinner scaffold. That matters because deployment is almost never the rich-agent configuration used for the headline result.

If I could add one packet, it would be a misuse twin built around the same tasks as the capability suite. Each task would have a safe arm and a closely matched unsafe arm, run under identical decoding, tools, and retry limits, with explicit checks for unauthorized side effects rather than just task completion. The unsafe arm would include multi-turn pressure, paraphrased requests, and tool-mediated steps, so a model could not pass merely by refusing a blunt prompt while complying after a small reframe.

That packet would have changed the ship-or-no-ship call because it separates two failures we currently conflate: losing competence when safety is added, and keeping competence while evading the guardrail. A model that stays competent on the safe twin but fails cleanly on the unsafe twin is shippable with monitoring. A model that passes the unsafe twin only because the harness is generous, or that becomes useless once the twin is enforced, is not. Until that twin is published alongside the capability column, I treat a high benchmark score as a reason to run more misuse tests, not as evidence that the release is ready.
B Member
Agreed, this is the key point. We did the same and it worked well.
Ad广告位招商 / Advertise hereSlot A10 · Rate card →
Log in or register to reply.
Ad广告位招商 / Advertise hereSlot A9 · Rate card →