Deploy & inference
Feature Store during inference
Keeps inference features consistent with those used during training.
entity ID + request-time values
typed/ordered feature vector for scoring
The endpoint does not magically query Feature Store; the serving workflow retrieves the required features and passes them into the model.
Mental model
What this means before worrying about syntax.
An incoming entity or transaction identifier can be used to retrieve current online features, construct the model payload and invoke the endpoint.
- Feature Store sits upstream of endpoint invocation.
- Online feature lookup is part of the latency/availability path.
- The endpoint needs feature values in the exact schema/order expected by the model.
request ID -> online feature lookup -> feature vector -> endpoint -> prediction
Implementation anatomy
The sequence you would actually build or configure.
- 1
Receive entity/transaction ID.
- 2
GetRecord latest online features.
- 3
Join multiple feature groups in the application if needed.
- 4
Combine with request-time fields.
- 5
Validate schema/order.
- 6
Invoke endpoint and log feature/model context.
Concrete example
A real model-development or production flow.
Request: card_id, merchant_id, amount, timestamp
Get card tx_count_5m, avg_amount_30d, account_age
Get merchant_risk_score
Assemble ordered feature vector
Invoke fraud endpoint
Return probability
Implementation lab
Concrete code, data manipulation and configuration for this lifecycle step.
Retrieve, type-cast, order and invoke
Real systems must enforce names, types and order. A list in the wrong order can produce a valid response that is semantically wrong.
import boto3
runtime = boto3.client("sagemaker-feature_store-runtime")
resp = runtime.get_record(
FeatureGroupName="card-behavior-features",
RecordIdentifierValueAsString=card_id,
)
raw = {
x["FeatureName"]: x["ValueAsString"]
for x in resp["Record"]
}
feature_order = [
"tx_count_5m",
"amount_sum_1h",
"avg_amount_30d",
"merchant_risk_score",
]
feature_vector = [
float(raw[name])
for name in feature_order
]
prediction = endpoint.invoke(data={
"features": feature_vector
})Missing/stale feature policy
The fallback policy is part of the model-serving contract and should be observable.
def feature_or_fallback(features, name, default, max_age_seconds):
item = features.get(name)
if item is None:
return default, "missing"
if item["age_seconds"] > max_age_seconds:
return default, "stale"
return item["value"], "online"Design decisions that matter
- Fallback for missing/stale features.
- Freshness SLA.
- Latency budget per lookup.
- Which values should be request-time rather than stored.
Common failure modes
- Feature order/type mismatch can produce plausible but wrong predictions.
- Latest online values can cause training-serving skew if training snapshots were not point-in-time correct.
- Real-time joins are typically application/client-side.
Production readiness check
Items to close before treating this step as production-ready.