Serve the features you trained on.
A model trained on the notebook's version of a feature and served a production approximation drifts silently. Signals builds the training set and serves the live value from one definition, so what the model learned from is what it reads at inference.
- Training
failed_searches_sessioncomputed as of each moment worth predicting fromThe dataset builder labels the moment and computes the attribute from only the events before it.
- NowThe same definition runs on the live stream
Streaming engine, kept current for every open session.
- +6msYour model reads it at request time
No second implementation to keep in step.
Notebook features never reach production.
The feature works in the notebook. Then someone rewrites it for the serving path, the two drift, and nobody notices until the model quietly degrades. Every new feature is another ticket and another copy to keep in step.
Define once. Train on history, serve on the stream.
Write the feature as an attribute
Counts, recency and order over the events you already collect, keyed on user, session or listing.
Build the training set from the same definition
Name the outcome. Signals labels your history and computes each attribute as it stood at that moment, into a table in your warehouse.
Read it at inference from the streaming engine
One call returns every feature in the service, in single-digit milliseconds.
| Attribute | Key | Window | Read by |
|---|---|---|---|
failed_searches_session | session | this session | Search ranker |
categories_viewed | user | 30 days | Recommendation model |
basket_value | basket | live | Offer model |
The model sees what it was trained on.
Streaming for now, batch for history
Second implementation of a feature for your team to maintain
Added at inference, p50 in-region
user · session · basket · listing · store
Start with one attribute.
Define it, read it in your own product, and see it change while you click around. 14 days, no card, no sales call.