Feature Store Observability: What it is, and why it matters
summary
Argues that feature stores need active observability not just alerts and claims a survey of ~1,000 companies shows incidents take about a week to detect and fix and roughly 50% of engineers lack root cause tools. Describes an ML observability stack using Arize to monitor data quality, drift, and performance, applies PSI for drift thresholds, pages via Slack or PagerDuty, and visualizes embeddings with UMAP visualization to export outlier segments for relabeling.
AI-written summary · about
chapters (8)
- 0:00Introduction to talk
- 1:24Production ML challenges
- 6:56Feature store in observability
- 9:20Data quality monitoring
- 10:26Understanding drift detection
- 13:58Performance tracing methods
- 16:25Observability for embeddings
- 18:55Summary and key takeaways
related talks
06mIgnite: Observability Observed
52mObservability: it's not just an ops thing
30mHow Feature Stores Enable Operational ML
33mWhat Developers Should Know About Observability
13mObservability Where are We Headed?
49mObservability in Practice: How to Become Proactive with Bugs
39mIs It Already Time To Version Observability? (Signs Point To Yes.)
29mObservability; a gentle introduction