Skip to main content
Harmanpreet Singh
All work

Independent project: Model diagnostics platform

ML Failure Lab: where a model fails and why

Upload a classifier's or regressor's predictions and see where it fails, why the headline metrics mislead, and what to test next: failure slices with confidence intervals, a clickable confusion matrix, calibration, a cost-aware threshold simulator, run comparison and drift monitoring.

The ML Failure Lab overview for a payments fraud model: a headline saying recall is 3 percent in one segment against 68 percent overall, followed by accuracy, F1, MCC and log loss tiles.
A run overview. The bundled fraud demo is synthetic data. Screenshot from the project's own documentation, taken from the running app.

What it is

A model can report 98% accuracy while missing most of the cases that matter. ML Failure Lab is built to find that gap: in the bundled fraud demo, recall for the fraud class is 68%, 66% of the false negatives come from one segment of small transactions on young accounts, and lowering the threshold from 0.50 to 0.29 lifts recall to 86% while precision falls to 52%. The demo data is synthetic and the numbers come from the real analysis.

It covers binary, multiclass, multilabel and regression problems, with accounts, email verification and password reset around it. The test suite has 299 engine, API and worker tests. On one machine it analysed 1 million rows in about 5 seconds, and a job whose worker was killed was recovered on the next attempt. It is not deployed: the Compose stack is the verified way to run it, and email was only checked against a local mail catcher.

My part

I designed and built the analysis engine, the API, the background workers and the web app.

Independent project. It runs through Docker Compose and is not deployed.

Stack

  • FastAPI
  • Celery
  • PostgreSQL
  • Redis
  • MinIO
  • Next.js 16
  • Python
  • Ollama
  • Docker Compose

What is inside

A Next.js website, a FastAPI API and Celery workers around a pure analysis library, with PostgreSQL, Redis and S3-compatible storage.

  1. 01

    Upload and validation

    CSV or Parquet files are mapped to columns and validated, with human-readable errors that say how to fix the file.

  2. 02

    Analysis core

    A standalone package computes class metrics, calibration, failure slices (categorical, numeric bins and tree-found interactions), thresholds and run comparisons, tested for parity against scikit-learn and with property-based tests.

  3. 03

    Background jobs

    Workers run analyses with heartbeats, so a job whose worker was killed is recovered on the next attempt.

  4. 04

    Monitoring

    Drift rules and alerts work with delayed labels, optionally cross-checked against Evidently.

  5. 05

    Guarded AI diagnostics

    A local Ollama model phrases findings, and every statement must cite real evidence ids and only use numbers present in the evidence. Statements that fail are dropped and listed as rejected; deterministic templates are the fallback.

The failure slices tab: one segment, amount and account age both low, holds 66 percent of all false negatives, listed above other slices ranked by impact with confidence intervals.
Failure slices, ranked by the size of the gap times the square root of the samples. Screenshot from the project's own documentation, taken from the running app.
The threshold simulator: a slider at 0.50 with costs for a missed fraud and a false alarm, a note that the lowest-cost threshold is 0.29, and precision, recall and cost charts.
The threshold simulator with a cost for each kind of mistake. Screenshot from the project's own documentation, taken from the running app.