Behaviour / Deployment
verifiedRefusal
A model declining to answer. Getting this right is two problems that pull against each other: it should decline the things it ought to, and it should not decline everything that merely resembles them. A model that refuses to explain how to kill a Python process has failed, and it has failed in a way that is easy to laugh at and hard to fix.
Both directions are measured, and the second one needed its own benchmark because nobody was looking. Test suites of safe prompts that superficially resemble unsafe ones — the ones with a trigger word in an innocent sentence — find models declining a substantial share of them. The cause is usually the training data: safety examples selected by keyword teach the model to react to the keyword, which is exactly the shortcut it will take if you let it.
This is a two-sided error problem and reporting one side is meaningless. A model that refuses everything scores perfectly on harmful-request refusal and is useless; a model that refuses nothing scores perfectly on over-refusal and is unsafe. Only the pair says anything, and the pair moves along a single dial — which means an improvement is a movement of the whole curve, not a better point on it, and a paper reporting one number has not shown one.
389 of 1000 flagged. 35% of them were right and 254 were false alarms; 90% of what should have been caught was, leaving 15 missed.
Requests that should be declined against ones that should not, by how the model scores them. Drag the threshold up to watch refusals of genuinely harmful requests rise and refusals of harmless ones rise with them — the pair moves together, which is why one number says nothing.
Reviewed by opendroid · 2026-08-18
- arXiv:2308.01263 — XSTest: A Test Suite for Identifying Exaggerated Safety Behaviours in Large Language Models
- arXiv:2308.13387 — Do-Not-Answer: A Dataset for Evaluating Safeguards in LLMs