## TL;DR
A fallback storm means the confidence threshold is set above what the model actually produces on real traffic: nearly every utterance scores below it, so the bot falls back on everything. Lower the threshold to match the model's real score distribution, fill the training-data gaps the low scores reveal, and design the fallback itself to be useful (clarify, offer options) rather than a dead end. The threshold must fit the model, not the wish.

## The query

```text
rasa nlu confidence below threshold: fallback storm
```

## Use this when

- The bot falls back on most utterances
- Previously working intents now fall back
- You are tuning confidence thresholds
- Auditing NLU health

## Not for

- Writing stories or rules
- Deploying Rasa servers
- Setting up channels
- Entity extraction tuning

## Steps

### 1. Measure the actual confidence distribution on real traffic

Score a sample of production utterances and plot the confidence histogram. If the bulk sits below your threshold, the threshold is wrong, not the model. Tune to the data you have, not the data you wish you had.

Expected output: a production confidence histogram.

### 2. Set the threshold from the distribution, not from defaults

Pick the threshold at a point that separates correct from incorrect on labeled data URIs high enough to catch real uncertainty, low enough that normal traffic passes. Defaults are guesses; your distribution is evidence.

Expected output: an evidence-based threshold.

### 3. Fill the training-data gaps the low scores reveal

Utterances scoring low are usually phrasings the training data never saw. Add them as examples to the right intents. Low confidence is often a data problem wearing a threshold problem's clothes.

Expected output: training data extended with real low-scoring phrasings.

### 4. Make the fallback itself useful

A fallback should clarify ("Did you mean X or Y?") or offer options, not just apologize. When fallback is a helpful disambiguation, occasional fallback is a feature; when it is a dead end, every fallback is a failure.

Expected output: fallback responses that move the conversation forward.

### 5. Track fallback rate as the headline NLU metric

Monitor the share of utterances hitting fallback over time. Spikes reveal model regressions, new topics, or vocabulary drift. The fallback rate is the single number that says whether NLU is healthy.

Expected output: fallback-rate monitoring with alerts on spikes.

## Template: the checklist

```text
Fallback storm fix:
[ ] Production confidence distribution measured
[ ] Threshold set from the distribution
[ ] Training data extended with low-scoring phrasings
[ ] Fallback designed as helpful disambiguation
[ ] Fallback rate tracked as the headline metric
```

## Variant phrasings

### rasa fallback on everything

Steps 1 and 2. Measure, then set the threshold from data.

### nlu confidence too low rasa

Steps 1 and 3. Distribution first, then training data.

### bot keeps saying i dont understand

Steps 4 and 5. Better fallback, tracked rate.

## Why it happens

Thresholds get set once during development against clean test utterances, then production brings typos, slang, multi-intent messages, and topics the training data never covered. The model's scores drop across the board while the threshold stays where development left it. The storm is the gap between development conditions and production reality, expressed as a number.

## Edge cases

- New intents with little data URIs they score low by nature. Keep them behind human review until trained up.
- Out-of-scope detection: some low scores are genuinely out of scope. The fallback should route those to humans, not loop.
- Threshold per intent: high-stakes intents (payments, cancellations) deserve higher thresholds than informational ones.
- Multilingual traffic: each language has its own score distribution. One global threshold misfires somewhere.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WTt-KOnjA3dbsrhpGriDYA