What happens to unseen values at prediction time?

With rare-bucketing they map to the rare token; with deletion they are typically ignored, which loses information silently.

Is a cutoff the same as feature selection?

It is one crude form of it, based on frequency or importance rather than domain judgment.

How do I choose the threshold?

Sweep a few candidates and measure held-out performance; the curve usually has a flat forgiving region.

Who should set the cutoff?

Data teams propose from validation curves, but rare-value whitelists need domain owners, who know which uncommon values carry weight.

AI Glossary / AI and machine learning / Intermediate

Feature cutoff

Definition

A feature cutoff is a threshold that drops feature values below a set frequency or importance, keeping the input space small enough to be useful.

What it means

In text and categorical data, most possible values are rare: thousands of words or product codes appear a handful of times. Rare values cost memory and training time while teaching the model almost nothing, because three occurrences is not a pattern.

A cutoff draws a line: values seen fewer than a chosen number of times are discarded, or lumped into a shared rare bucket. The model then spends its capacity on values that appear often enough to generalize.

The same idea applies to feature importance: after a first model pass, fields contributing less than a threshold of predictive power can be cut, simplifying the model for its next iteration.

Cutoffs trade a little information for a lot of tractability. Set the line too low and noise survives; too high and real but uncommon signals, the exact rare word that matters, get discarded with the junk.

For a business, cutoffs are why production feature lists are short: they are the gardening that keeps a ten-thousand-column haystack down to a few hundred needles the model can actually learn from.

Cutoffs also interact with fairness review: a threshold can silently remove the categories small groups belong to, so check which populations fall below the line before drawing it.

How it works

Count how often each value or feature occurs in the training data.

Choose a minimum count threshold, by validation experiment or by rules of thumb such as dropping values seen fewer than five times.

Apply the cutoff: discard sub-threshold values or map them to a shared rare token, so unseen values at prediction time have somewhere to go.

Alternatively, rank features by importance from a first model and cut those below a chosen contribution level.

Re-check the cutoff whenever the data volume or vocabulary changes, because a threshold tuned on last year's data silently tightens or loosens as the data shifts.

Three practical examples

Text classification: keeping the 20,000 most frequent words and mapping the rest to a rare token.
Retail: grouping product codes bought by fewer than ten customers into an other bucket before modeling.
Model simplification: dropping the bottom half of fields by importance after a first-pass forest.

Think of it this way

Think of a conference with limited seats. Below some seniority, attendees are grouped as observers rather than given individual speaking slots. The cutoff is the seniority line: it loses a few voices worth hearing and saves the meeting.

The limit: the line decides who counts as rare, and rare is not the same as unimportant. A whistle-blower attends once. Worth checking what your threshold would have silenced.

Worked example

cutting a support-ticket vocabulary

Suppose a support classifier's text input contains 90,000 distinct words, most appearing once or twice. The figures are illustrative.

A cutoff at five occurrences reduces the vocabulary to 18,000 words, cutting training time by 60 per cent with no measurable accuracy loss.

The team maps discarded words to a rare token rather than deleting them, so unusual words in new tickets still register as something.

They also whitelist 40 domain terms below the threshold, product names and error codes, protecting rare words that carry weight.

Illustrative case study

A fictional marketplace applied an importance cutoff to its search ranking model and removed a field about accessibility preferences, because it influenced few predictions on average.

Complaints followed from the minority for whom that field was the whole decision. The cutoff was statistically correct and operationally wrong.

The invented lesson: average importance is not the only importance. Fields that matter intensely to a few can matter more than fields that matter slightly to all.

Common misconceptions and mistakes

A cutoff deletes data. It simplifies the model's inputs; the underlying records are untouched.
Rare values are always noise. Rare values are mostly noise and occasionally the whole story, which is why rare-bucketing beats deletion.
One cutoff fits all time. Frequencies drift; a fixed threshold on a growing dataset admits ever more noise, and on a shrinking one discards ever more signal.

Business use

Use rare-bucketing rather than deletion as the default cutoff mechanism, so unusual future values degrade gracefully instead of vanishing.

Whitelist known load-bearing rarities, error codes, product names, regulated categories, before applying any frequency line.

Record cutoff thresholds in the model documentation and review them on data refreshes; they are settings, not constants.

Publish the cutoff table beside the model card: which fields were trimmed, at what threshold, and what fraction of values each trim affected.

Check your understanding

Why does mapping rare values to a shared bucket usually beat deleting them?

Answer: Because deletion makes unusual values invisible while bucketing preserves the fact that something unusual occurred, which is often itself a signal.

Related terms

Learn next

AI for Business Owners covers the judgment calls that keep a model's inputs small, honest and defensible: https://aiforbusinessandlife.com/academy/ai-for-business-owners. [C2]

Sources

[S8] Jurafsky and Martin, Speech and Language Processing (3rd ed. draft). Full URLs are in the source ledger. Verified 11 October 2026.

Previous: Feature cross Next: Feature descriptor