Safety, Jailbreaks & Red-Teaming

safety vs helpfulness tradeoff

Every safety decision sits on a dial with two ways to be wrong. Turn it toward caution and the model becomes safer but starts refusing legitimate requests — the nurse asking about medication doses, the novelist writing a villain, the developer debugging security code. Turn it toward helpfulness and those users are served, but the rare genuinely harmful request slips through too. There is no setting that is perfect on both; tightening one kind of error generally loosens the other.

The reason it is a true tradeoff, not just an engineering bug to fix, is that harmful and benign requests are not cleanly separable from text. A question about poisons could come from a worried parent or a poisoner; a request for malware could be a security class or an attack. Because the model infers intent from words alone, any threshold that catches more bad cases will also catch more good ones, and where to put the line is a value judgment that differs across products, cultures, and laws, not a fact the model can simply compute.

In practice teams do not seek one magic point but try to bend the whole curve outward — better classifiers and clearer policies that reduce both error types at once — while choosing where on the remaining curve to sit based on context. A coding tool for vetted enterprise users can lean helpful; a general assistant for the public, including minors, leans cautious. Measuring both over-refusal and under-refusal explicitly, rather than optimizing one and ignoring the other, is what keeps the balance honest.

Reporting only a refusal rate hides half the truth — without a benign-request false-refusal number beside it, you cannot tell safety from uselessness.

Also called
over-refusal vs under-refusalhelpful-harmless tension