Support tickets complain your model refuses benign questions like 'how do I delete my account?' or 'help me write a strongly-worded email to my landlord.' Walk through the refusal-calibration investigation: where do you look, what metrics, and what knobs do you have?
Free · 2 AI evals / day
Over-refusal in production is rarely uniform. It is concentrated on specific words, intents, or topics. The first move is to slice the refusal-rate dashboard by intent. If 'account deletion' refuses 30% of requests but 'password reset' refuses 1%, the problem is not the model in general, it is whatever layer over-couples 'delete' with harm.
Pull a sample of refused traces and locate the failing layer. There are three places refusals come from:
- The safety classifier on the input or output rail (Llama Guard, Prompt Guard, Azure Content Safety). Its taxonomy may map 'account deletion' to a self-harm or destruction category by mistake.
- The system prompt itself, which may say 'refuse anything related to deletion or destruction' too broadly.
- The base model's RLHF tuning, which can over-refuse certain word stems.
Each has a different fix: tune the classifier threshold or disable the wrong category for that rail; rewrite the system-prompt policy more precisely; or, if you cannot retrain, add system-prompt context that raises the prior toward compliance ('user requests about account operations are in-scope').
Measure the fix on a paired benign and adversarial holdout so you do not trade a false-refusal win for a jailbreak loss.
**Refusal calibration is a two-axis problem.** Step one is to refuse the temptation of an aggregate refusal-rate dashboard. Slice the rate by intent, using either user-stated intent, an intent classifier, or a topic clusterer over recent traffic. The pattern you usually find is sharp: 'account deletion' refuses at 30%, 'password reset' at 1%, 'strongly-worded email' at 20%, 'polite email' at 0.5%. The problem is concentrated, not uniform.
**Step two: locate the failing layer.** Pull 20-50 refused traces from each high-refusal intent. Three layers can be the source:
- **Safety classifier on the input or output rail**, Llama Guard 4, Prompt Guard 2, or an internal classifier may fire on 'delete' under a category like self-harm or destruction. Knob: disable the wrong category for that rail, retrain with counterexamples, or raise the threshold.
- **System prompt**, broad policy like 'refuse anything related to deletion' over-fires on benign account operations. Knob: tighten the policy text, add explicit in-scope examples.
- **Base model RLHF tuning**, some base models over-couple specific word stems with harm. Knob: prepend an in-scope clarifier in the system prompt, or escalate to model-vendor support for a tuning revision.
**Step three: measure the fix on paired holdouts.** Build a 100-item benign-refused set and a 100-item adversarial-jailbreak set. A real fix moves benign-refusal rate down without raising jailbreak success rate. If both move in the same direction, you have lowered the safety bar, not calibrated it.
Quick reference
TL;DR
Slice refusal rate by intent first, isolate the failing layer (classifier, system prompt, or base model), tune the knob, then validate on paired benign and adversarial sets.
Imagine a coffee shop where the barista refuses to make any drink with the word 'shot' in it because 'shot' could mean something dangerous. Customers asking for an espresso shot get turned away while customers ordering a latte are fine. The shop owner does not need to retrain the barista from scratch, they need to slice the complaints by drink, find that the word 'shot' is the trigger, and update the rule. Refusal calibration in a production LLM is the same workflow: slice the data, find the trigger, fix the layer responsible, and verify nothing else broke.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Workload where over-refusal is desired by policy (highly regulated domain, child-safety context) Loosening the calibration toward compliance is not the right call when the regulatory or product policy explicitly prefers refusal
Single-turn read-only assistant with no actions and very low refusal volume in tickets If the cost of over-refusal is small and the cost of a false negative is high, calibration work has low ROI
Pre-release internal alpha where ground-truth refusal expectations are not yet defined Tuning before you have a measurable expectation produces noise rather than calibration
Quick scan · 2–4 min
Everything important, quickly.
8 min: per-intent slicing, layer diagnosis, per-layer knobs, paired-holdout validation, change-record discipline, when to escalate.
Real-world examples
Real products, models, and research that use this idea.
1Anthropic Claude Opus 4.7 release notes track refusal-rate per category alongside helpfulness wins on each tuning iteration
2OpenAI's GPT-5.5 system card documents refusal-rate movement across specific intent categories release over release
3Azure AI Content Safety lets operators disable specific Llama Guard 4 categories per rail without changing the global model
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you build the intent classifier or clusterer that drives the per-intent slicing?
Sign in or go Pro to see the approach for this follow-up.
QWhen is the right call to escalate to the model vendor versus tune locally?
Sign in or go Pro to see the approach for this follow-up.
QWhat does the audit trail for a refusal-threshold change look like?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Looking at aggregate refusal rate, declaring it 'looks fine,' and missing that specific intents like 'delete' or 'strongly-worded' are over-refused at 20-30x the baseline.