AI Glossary / AI and machine learning / Intermediate
On-Demand Features
Definition
On-demand features are computed at the moment a prediction is requested, from the freshest available data, rather than being pre-computed in a batch and stored for later use.
What it means
The distinction is about freshness. Batch features are computed nightly and served all day; on-demand features are computed at request time, so the model sees the account balance now, the basket contents this second, the location this minute.
Freshness buys accuracy wherever the world moves fast: fraud, recommendations, pricing and availability all degrade when the model reads yesterday's state of a situation that changed an hour ago.
The cost is engineering: the computation must run inside the request's time budget, reliably, at traffic scale, which is why on-demand features live behind feature-serving infrastructure rather than in notebooks.
The subtle danger is training-serving skew: the feature must be computed identically in training and at request time, or the model learns one definition and is served another.
For a business, the on-demand question is a freshness budget: which decisions actually degrade by the hour, and are you paying real-time engineering prices only for those.
Feature stores exist partly to manage this split: batch features in one tier, on-demand computation in another, with one registry keeping the definitions honest.
How it works
List the features the model needs and mark which genuinely degrade with age: balances and baskets age in minutes, demographics in years.
Compute the perishable features at request time within the latency budget, serving the stable ones from batch storage.
Keep one shared definition per feature, implemented once and used by both training and serving, to kill the skew.
Monitor the on-demand path like a customer-facing system: latency, failures and the fallback when the fresh source is down.
Define the fallback explicitly, last known value or a safe default, because a timed-out feature should degrade the answer, not crash it.
Three practical examples
- A fraud score computed on the account's balance and last ten transactions at the moment of the attempted payment.
- A ride app's ETA model reading driver positions and traffic at request time, refreshed by the second.
- A recommendation feed ranking items against the user's clicks from the current session, not last night's profile.
Think of it this way
Think of a market stall versus a supermarket price list: the stallholder prices from this morning's stock and this customer's haggling, while the list was printed last night. Both work; only one knows what is happening now.
Worked example
the ninety-minute fraud window
Suppose a bank's fraud model reads daily batch features, and a stolen card runs twelve transactions between midnight and 6 AM. The figures are illustrative.
Every transaction is scored on yesterday's account state, so the model sees each one in isolation and approves eleven of twelve.
Switched to on-demand features, balance now, transactions in the last hour, the model catches the pattern at transaction four.
The difference was not the model but the clock: the same features, computed at request time, turned a serial loss into an early catch.
Illustrative case study
A fictional retailer built on-demand basket features for its checkout recommendations, computed one way in training scripts and a subtly different way in the serving service.
The model performed beautifully in testing and oddly in production for months, until a side-by-side comparison showed the two implementations diverged on empty baskets.
The invented lesson: an on-demand feature is one definition in two places. If the two are not the same code, they are not the same feature.
The fix was to unify: one shared feature library serving both training and requests, with edge-case tests that run on every deployment.
Common misconceptions and mistakes
- Fresher features always help. They help where the world moves fast; stable features gain nothing from real-time prices.
- On-demand is just faster batch. It is a different architecture with latency, reliability and skew problems of its own.
- Skew is a minor detail. A definition gap between training and serving silently invalidates the model, and it is the most common real-time failure.
Business use
Pay on-demand prices only for features whose staleness measurably costs decisions.
Insist on one shared implementation per feature across training and serving, and test it on edge cases like empty histories.
Design the fallback for source outages before launch, and rehearse it.
Monitor feature latency and failure rates as first-class operational metrics, not engineering trivia.
People also ask
What are on-demand features?
Features computed at prediction request time from the freshest data, instead of pre-computed batches.
When are they worth it?
When the underlying state moves fast: fraud, availability, live pricing and session-based recommendation.
What is training-serving skew?
A definition gap where the feature is computed differently in training and in production, silently invalidating the model.
What happens when the live source is down?
The designed fallback runs: last known value or a safe default, degrading the answer gracefully instead of failing.
Can a model mix batch and on-demand features?
Yes, and most do: stable fields served from storage, perishable ones computed live, under one shared definition each.
Check your understanding
Why is a shared feature definition the critical control for on-demand features?
Answer: Because the feature is computed in two places, training and live serving, and any divergence between them means the model learned one quantity and is fed another, so the entire model's validity rests on the two implementations being provably the same.
Related terms
- Feature engineering
- Training-serving skew
- Machine Learning Pipeline
- Latency
- feature store
- real-time
Learn next
AI Agents and Automation for Small Business shows where real-time data earns its engineering cost: https://aiforbusinessandlife.com/academy/ai-agents-automation-small-business. [C4]
More in AI and machine learning
- NSynth - NSynth is a neural audio-synthesis research project that learns representations of musical notes and uses them to generate sound.
- Numerical data - Numerical data is data that lives on a number line: quantities with magnitude and order, like revenue, temperature, age or count, where arithmetic means...
- Oblique condition - An oblique condition is a decision-tree split on a combination of features at once, a slanted line through the data, rather than the usual single-feature...
- One-hot encoding - One-hot encoding turns a category into a set of yes-no columns: 'city' becomes one column per city, with a 1 in the item's own city and 0 everywhere else...
- One-hot vector - A one-hot vector is the row of switches that represents one item's category: all zeros except a single 1 in the position of the category the item belongs to.
- One-shot learning - One-shot learning is learning to recognize a category from a single example: show the system one photo of a new product, one recording of a new voice, and...
Sources
[S7] Hopsworks, MLOps Dictionary; [S2] Google, Machine Learning Glossary. Full URLs are in the source ledger. Verified 11 October 2026.
Previous: Omniscience Next: On-line SPC