Databricks ML Professional Practice Question 14: On Demand Feature Function
Databricks Certified Machine Learning Professional · Test 2 · question 4 of 10
A fraud model needs a feature defined as the ratio of the current transaction's amount to the cardholder's 30-day average, plus the minutes elapsed between the request timestamp and the cardholder's last login. Both depend on values that arrive with the scoring request, so neither can be precomputed and stored. The identical computation must be used during training and at sub-second serving time.
What should the team implement?
Show answer and explanation
Answer:
This is what on-demand features are for: values that depend on request-time inputs and therefore cannot be materialised in advance. The logic is written once as a Unity Catalog Python UDF, bound to its inputs by a FeatureFunction in the feature_lookups passed to create_training_set, and logging with fe.log_model records that binding in the model itself. Training rows are computed by the UDF, and at serving time the model invokes the same UDF per request, one definition, governed and discoverable in Unity Catalog, which is precisely what eliminates online/offline skew.
Option A cannot produce the feature at all. The ratio depends on the amount in the request being scored, which does not exist until the request arrives; no refresh interval, however short, makes a precomputed row match it.
Option B is the classic source of skew. Each client reimplements the formula, and any divergence from the training-time version silently degrades the model, the problem on-demand features were introduced to remove.
Option C makes training work and serving wrong. Defaulting a feature at inference feeds the model a distribution it never saw, and the two most informative signals become constants in production.
Reference: Compute features on demand using Python UDFs