Set icon
Query icon
Script icon
UploadFiles icon
If icon
Subflow icon
Request icon
Switch icon
Log icon
Fail icon
Schedule icon

Monitor a model's real performance once its delayed outcomes arrive

Monitor a deployed model in Kestra. Join PostgreSQL predictions with delayed outcomes, judge mature cohorts, flag real AUC or Brier drops, start retraining.

Categories
AIData

Input drift tells you the data changed, not that the model got worse. For many models the truth arrives weeks later: a loan defaults, a customer leaves, a trip ends. This flow joins your prediction log with those outcomes, judges only the cohorts old enough to have them, and tells you when the model's real performance has dropped.

How it works

  1. mark_pending sets the verdict in KV to PENDING, so a run that crashes never leaves an old HEALTHY.
  2. query (PostgreSQL) joins predictions with the outcomes known at as_of, drops predictions younger than label_maturity, and aggregates per cohort and score bin in the database. Only counts leave it.
  3. evaluate (Python) computes AUC and Brier score with standard errors per cohort, leaves out cohorts with too few outcomes (INCONCLUSIVE), and compares the rest with the baseline stored in KV.
  4. A cohort is DEGRADED only when the drop is larger than your tolerance and more than three standard errors from the baseline.
  5. The report goes to namespace files, the verdict and history to KV. When enough cohorts in a row are degraded, retrain starts your retraining flow; alert posts to a webhook.

What you get

  • Flow outputs: verdict, healthy, summary, cohorts, report_markdown, retrain_started.
  • ml-monitor/<model_name>/performance_report.md with every cohort, its coverage and the method.
  • KV ml_<model_name>_performance, _baseline and _history.
  • as_of replays a past date to see when the monitor would have fired.

Who it's for

  • ML engineers and data scientists running scored models whose outcomes arrive later (credit, churn, fraud, ETAs).

Why orchestrate this with Kestra

  • The schedule, SQL, statistics, KV baseline, report, alert and retraining call are one audited execution, and the verdict feeds a deploy or retrain flow.

Prerequisites

  • A PostgreSQL database with a predictions table (prediction_id, model_name, predicted_at, score between 0 and 1) and an outcomes table (prediction_id, outcome 0 or 1, observed_at), one outcome row per prediction. Names are in variables. Rows that break these rules stop the run instead of being skipped.
  • A Docker-capable worker for the Python task.

Secrets

  • ML_DB_PASSWORD: password of the database user.

Quick start

  1. Add the secret and edit variables for your database and tables.
  2. Run once with mode: SET_BASELINE, as_of at the end of the validation period and label_maturity for your outcomes.
  3. Run with mode: MONITOR (leave as_of empty), then enable the daily trigger.
  4. Set retrain_namespace and retrain_flow_id to start retraining.

How to extend

  • Add a segment column to monitor each customer group, or send the verdict to a model registry.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.