How can feature definitions be shared across training and serving?

Share a versioned feature contract and reusable transformation implementation between model training and live inference. Both paths must agree on the feature's meaning, inputs, units, missing-value rules and output type—even when one runs on historical batches and the other handles single requests.

Question 95 covered ownership and discovery. Here the engineering challenge is preventing different computations for the same feature.

Worked example: delivery-time prediction

A model uses delay_ratio, defined as restaurant delay divided by estimated travel time, clipped to a range from 0 to 5.

• Historical training row: restaurant_delay_min = 8, travel_time_min = 20.
• Shared definition: min(max(8 / 20, 0), 5) = 0.40.
• Live inference for the same input values must also return 0.40, not 40, 0.4%, or a value calculated with seconds instead of minutes.

If the online implementation accidentally divides by travel time in seconds (1,200 instead of 20), it computes 8/1200 ≈ 0.0067. That is a 60× smaller value than expected. The model sees training-serving skew even though the source records are otherwise correct.

One shared, testable transformation

For simple deterministic transformations, keep one pure function in a versioned Python package, usable from batch processing and inference services:

PYTHON
def delay_ratio(delay_minutes: float, travel_minutes: float) -> float:
    if travel_minutes <= 0:
        raise ValueError("travel_minutes must be positive")
    return min(5.0, max(0.0, delay_minutes / travel_minutes))

assert delay_ratio(8.0, 20.0) == 0.4

• Training: apply the function to eligible historical records before fitting the model.
• Serving: use the same tested package version on current eligible feature values.
• Package once, pin its version in both environments, and verify identical output for the same inputs.

This is easy for small transformations. For very large datasets, calling a Python function row-by-row may be inefficient; share a common declarative definition or generate equivalent warehouse and serving implementations, then test their results against each other.

How a feature store helps

Feast FeatureViews define entities, data sources, fields and schema for both offline historical retrieval and online serving. OnDemandFeatureViews can define Python transformations applied in historical and online retrieval paths; their current documented support and scaling limitations must be checked for the installed Feast version. <See official Feast FeatureView documentation.>

A shared repository can contain:

1. The feature views and entity contracts.
2. Transformation functions or authoritative SQL expressions.
3. Feature services identifying the exact bundle expected by a model.
4. Schema and golden-input tests.
5. Versioned configuration and release records.

A FeatureView by itself does not guarantee that upstream transformations are identical across independently implemented batch and streaming pipelines. Validate the complete calculation path.

Define the feature contract explicitly

For delay_ratio_v1, document:

• Entity: Restaurant or delivery request key used for the lookup.
• Inputs: restaurant_delay_min and travel_time_min, both floating-point minutes.
• Output: Float in the inclusive range 0–5.
• Formula: Clamp delay / travel to the allowed range.
• Null handling: Do not silently replace missing values with zero; follow an agreed missing-value policy.
• Zero denominator: Reject or use a separately designed fallback, identical in training and serving.
• Time meaning: Which historical feature values are eligible for a training or inference request.
• Version: An immutable or traceable definition identifier, such as delay_ratio_v1.

Documenting a feature is not enough: automated contract tests must enforce it. Detailed general schema validation is addressed in Question 97.

Versioning and synchronized deployment

Suppose the team wants to change the formula to include weather risk. Do not silently change delay_ratio_v1 in place while an already-trained model expects the old meaning.

A safe pattern:

1. Create delay_ratio_v2 with a clearly described new contract.
2. Publish its implementation and run equivalence tests across historical and online paths.
3. Backfill or populate required feature values where applicable.
4. Train and evaluate a new model using v2, recording the feature definition revision.
5. Deploy compatible feature-serving code and validate availability.
6. Roll out the new model only when all required v2 features can be served.
7. Keep v1 available until older model deployments and rollbacks no longer depend on it.

Compatibility is a pair: A model version and the feature-definition versions it expects must be deployed together or protected by backward-compatible serving interfaces.

A consistency test with numbers

Construct a small golden dataset:

• Input delay=8 min, travel=20 min → expected 0.40.
• Input delay=60 min, travel=10 min → expected 5.00 after clipping.
• Input delay=0 min, travel=10 min → expected 0.00.
• Input delay=8 min, travel=0 min → expected validation failure.

Run exactly those cases through the historical training transformation and the online serving transformation. Assert the same outputs, error behavior, units and data types. For floating-point results, use a declared tolerance such as abs(offline-online) <= 1e-6 when appropriate; do not demand bitwise equality between different numeric runtimes without reason.

Also compare sampled materialized online feature values with the corresponding expected offline snapshots at compatible timestamps. An age-related mismatch is different from a transformation-logic mismatch.

Common implementation patterns

• Single library: Reuse a common function across training and inference, suitable when both environments can run the same language/runtime.
• Shared SQL or declarative specification: Keep one source definition and compile it into supported execution engines; beware engine-specific date, null and type semantics.
• Feature-store-managed transforms: Use a feature platform's supported shared transform abstraction, including Feast on-demand feature views where suitable.
• Precompute once, serve many: Produce authoritative feature values upstream and load them into online storage, limiting the amount of transformation repeated during inference.

Choose based on scale, supported languages, runtime latency, infrastructure and maintainability.

Limitations and production traps

• Reusing the same source code does not make historical data and live feature values equally recent.
• Different SQL engines may interpret missing values, timestamps, integer division and numeric precision differently.
• A feature-store definition does not guarantee data ingestion, source and transformation logic are synchronized.
• Changing a shared library may break previously trained models unless package versions are pinned.
• Request-time features such as live trip distance might not exist in historical warehouses; training needs representative historical request values.
• Expensive Python transformations during large offline retrieval may cause unacceptable costs; use scalable execution for heavy computations.
• Test rollback: restoring an old model may require restoring its expected older feature interface.

In short: Share and version the feature contract, transformation implementation, golden tests, and model-to-feature dependencies. Deploy feature definitions and trained models compatibly, then verify offline/online outputs. Reuse reduces training-serving skew, but it does not replace freshness, timestamp and data-quality controls.