← Back to Portfolio

DriftGuard-ML

An end-to-end MLOps system providing automated statistical drift detection, real-time monitoring, and a Champion-Challenger retraining pipeline.

Business Context

Manual monitoring and retraining of ML models consumes hundreds of engineering hours per month. Automation ensures models remain highly accurate safely.

Technical Context

Needed a robust statistical backend (KS-Tests) coupled with an observable dashboard and a safe deployment strategy (atomic model swapping).

Architecture Flow

Production Data
→
Drift Detector
→
KS-Test
→
Chi-Square
→
Alert Engine
→
Retraining Pipeline
→
Champion/Challenger
→
Production Model

Component Breakdown

  • Inference Layer: FastAPI serving predictions with sub-50ms latency.
  • Logging Layer: MongoDB Atlas capturing all features and predictions.
  • Monitoring Pipeline: Statistical drift detector executing batch evaluations.
  • Retraining Pipeline: Champion vs Challenger model versioner.

Data Flow

  • Production traffic hits the FastAPI server; predictions are logged to Mongo.
  • A batch job runs KS-Tests on numerical data and Chi-Square on categorical data.
  • If drift exceeds thresholds, the Alert Engine triggers the retraining pipeline.
  • The Challenger model is trained; if MAE improves by >1%, it replaces the Champion.

Infrastructure

ModelsScikit-Learn Random Forests (Versioned .pkl files)
DatabasesMongoDB Atlas
CachingNone
APIsFastAPI REST Endpoints

Engineering Deep Dive

Challenges

  • Race Conditions: Updating the production model file (.pkl) while the server was processing concurrent requests caused file locking errors.
  • False Positives: Initial drift tests triggered retraining too often due to normal variance in small batch sizes.
  • Safety: Ensuring a newly trained model didn't perform worse than the degraded model.

Technical Decisions

Champion-Challenger Strategy

Required the new 'Challenger' model to beat the 'Champion' model by a strict margin before atomic promotion to prevent performance thrashing.

MongoDB for Log Storage

Document databases are ideal for storing flexible, changing schemas as model feature inputs evolve over time.

Results & Metrics

99.9%
System Uptime
During automated retraining phases.
<50ms
Latency
For P95 inference requests.

Lessons Learned

  • Atomic deployments and file-locking are critical for serving models in high-concurrency environments.
  • Statistical thresholds for drift (p-values) must be tuned carefully to avoid alert fatigue.

Recruiter Takeaways

AI Engineer

Understands the complete model lifecycle post-deployment.

ML Engineer

Strong MLOps skills, including monitoring, alerting, and CI/CD for models.

Startup Founder

Builds resilient systems that heal themselves without manual intervention.

Software Engineer

Familiar with concurrency, database logging, and API design.