Stop training-serving skew with Feast: build point-in-time training sets, serve features online and prove both paths match with a parity check.
Tuesday, the week after the acme-shop sale. The fraud model's validation recall is about 0.77.
A feature store is a real piece of infrastructure with its own storage, jobs and on-call. Many teams adopt one too early.
Leakage through joins is the most expensive bug in this module, because it makes a model look better in validation than it will ever be in production.
This is where the platform track starts. Feast describes features with a few Python objects.
With the definitions applied, Feast can build a point-in-time correct training set in one call.
Training reads history. Serving needs the latest value for one account in a few milliseconds.
Tuesday, the week after the acme-shop sale. The fraud model's validation recall is about 0.77.
A feature store is a real piece of infrastructure with its own storage, jobs and on-call.
Leakage through joins is the most expensive bug in this module, because it makes a model look better in validation than...
This is where the platform track starts. Feast describes features with a few Python objects.
With the definitions applied, Feast can build a point-in-time correct training set in one call.
Training reads history. Serving needs the latest value for one account in a few milliseconds.
In the Model Serving module, every feature arrived in the request.
A laptop Feast repository proves the idea.
Feast is a good default because it is open source, runs on a laptop and plugs into stores you may already have.
This lab is the platform track. You will build a Feast repository for account features, pin down the exact meaning of a...
Quick reference Common mistakes Computing the same feature twice, once in the training pipeline and once in the serving...
Roles that use the skills in this module.
AI Engineer
MLOps Engineer
Platform Engineer
Not a software engineer sheet. Every problem comes from real DevOps, SRE, Platform and Cloud interviews, from your first script to a system you build yourself.
Open the Coding SheetUsually not. If one model uses features that arrive with the request, or a nightly batch job computes everything, a well-tested feature function shared by training and serving is enough. A feature store starts paying off when several models reuse the same features, or when serving needs precomputed values such as counts over the last 24 hours.
The offline store holds the full history of feature values and is used to build training sets with point-in-time joins. The online store holds only the latest value per entity, such as per account, and answers lookups in a few milliseconds while a prediction request waits. Materialization is the job that copies the latest values from offline to online.
A point-in-time join gives each training row the feature values that were known at that row's timestamp, never values from later. Without it, a training row can see information from the future, such as a chargeback that arrived after the payment, and the model looks far better in validation than it will be in production.
Mostly no. Feast stores, serves and joins features that your pipelines have already computed, for example with SQL, pandas or Spark. It also supports on-demand transformations computed at request time, but the heavy aggregation work usually stays in your own pipeline code.