We can't see the true new distribution, only samples. So drift detection = a two-sample test: is the recent batch drawn from the same distribution as the training/reference batch?
We want a single number for "how much did a distribution move?" Start with the idea of comparing two probability distributions bin-by-bin. Split the feature range into B bins. Let ei = fraction in bin i for the expected (reference) data, ai = fraction for actual (new) data.
A natural asymmetry-tolerant way to compare two probabilities is the difference weighted by the log-ratio (this is the symmetrised per-bin relative entropy):
PSI=∑i=1B(ai−ei)lneiai
Rules of thumb: PSI <0.1 = stable; 0.1–0.25 = moderate shift, investigate; >0.25 = major shift, act.
WHY the sup of the CDF gap? The CDF captures the whole distribution shape; the largest vertical gap is the worst-case disagreement. A p-value from the KS test tells you if that gap is bigger than sampling noise.
If ground truth arrives (even delayed), the gold standard is just recomputing the metric on a sliding window:
Accuracyt=∣Wt∣1∑(x,y)∈Wt1[y^(x)=y]
Ground truth is often delayed (did the loan default? — wait months) or expensive (human labels). That's exactly why input/prediction drift are used as early proxies.
What two-sample question underlies all drift detection? ⇒ Are recent samples from the same distribution as reference?
PSI is 0 exactly when…? ⇒ the two distributions are identical.
Monitoring vs observability in one line? ⇒ Monitoring = "is it broken?"; observability = "why?"
Why are input/prediction drift used as proxies? ⇒ Ground truth is delayed/expensive.
Data drift vs concept drift? ⇒ P(X) changes vs P(Y∣X) changes.
Recall Feynman: explain to a 12-year-old
Imagine you trained your dog to fetch a red ball. Now you go to a park where everyone throws blue balls. Your dog still runs, still looks happy — but keeps bringing back the wrong thing, and it never tells you it's confused. Model monitoring is like putting a little camera on the dog: you watch what balls are being thrown (inputs), what the dog brings back (predictions), and sometimes check if it's actually right (labels). If the balls turned blue, an alarm rings so you can re-train the dog before your whole game is ruined.
Dekho, model deploy karne ke baad kaam khatam nahi hota — asli tension tab shuru hoti hai. Aapka model test set pe 95% laaya, matlab usne purane data ka pattern seekh liya. Lekin duniya badalti rehti hai: naye users aate hain, product change hota hai, data pipeline break ho jaati hai. Model crash nahi karta, bas chupchaap galat predictions deta rehta hai aur HTTP 200 bhejta rehta hai. Isi silent failure ko pakadne ke liye monitoring karte hain.
Do main cheezein yaad rakho. Data drift matlab input distribution P(X) badal gaya. Concept drift matlab input se output ka rishta P(Y∣X) hi badal gaya. Inko detect karne ka simple funda: do-sample test — kya naya batch usi distribution se aaya hai jaisa reference tha? Iske liye PSI (∑(ai−ei)ln(ai/ei), agar > 0.25 to bada drift) ya KS statistic (dono CDF ke beech ka sabse bada gap) use karte hain.
Ek important baat: monitoring bolta hai "kuch toota hai kya?", aur observability bolta hai "toota to kyun toota?". Jab accuracy giri, tab logs/traces se aap segment-wise slice karke root cause dhoondh sakte ho — jaise "sirf DE country ke users me income feature null aa raha hai". Isliye blindly retrain mat karo; pehle check karo — kya sach me performance giri, ya sirf pipeline bug hai. Yaad rakho PIPES — Performance, Inputs, Predictions, Errors/latency, Segments — sab clean rakho, tabhi production model bharosewala rahega.