Lab 08: Monitoring (FSDL 2022)

Model monitoring for a production text recognizer has to go beyond infrastructure health checks and into “behavioral” signals—whether the system’s outputs are actually correct and whether they could upset users. The lab builds that feedback loop by adding Gradio-based flagging controls (“incorrect,” “offensive,” “other”), then routing those user judgments—along with the input image and model output—into Gantry for centralized logging and analysis. Cloud metrics like EC2 and Lambda health in CloudWatch can catch outages, but they won’t alert when a model confidently returns garbage text; user feedback and model-specific metrics are what fill that gap.

The workflow starts with a small UI change: enabling Gradio’s flagging mechanism so users can label problematic predictions. When a user flags an example, the system initially stores a local CSV containing references to the uploaded image plus metadata about the prediction and the chosen flag. Because binary data is stored separately, the CSV keeps pointers to local files, and analysis requires reloading those images when needed. The lab then argues that local logging doesn’t scale well for production, so it replaces the local approach with a Gantry logger callback. That callback follows a two-step pattern: upload the image to S3, then send Gantry the S3 URL plus structured metadata (model output text, user-selected flag, and other context). From there, the notebook can pull logged records back into pandas for exploratory analysis, while Gantry’s UI supports the same investigation interactively.

In Gantry, the monitoring dashboard highlights how many feedback events arrive over time and which categories dominate. In the lab’s production window, most flags fall under “incorrect,” which is treated as a healthier sign than “offensive” or “other.” To catch harmful content automatically, the lab adds “detoxify” projections—scores for obscenity and related risks—computed on logged outputs. When an obscenity score bumps upward, the key question becomes whether it reflects real model behavior or just user-provided inputs containing swear words. With enough data, the lab emphasizes distribution comparisons: production values are compared against a trusted baseline from the model’s validation/testing sets. In this case, obscenity values are higher in testing than in production, reducing concern that the model is generating worse content than expected.

The monitoring system also supports debugging, not just alerting. By projecting output-text entropy, the lab detects a concerning shift: production shows more low-entropy outputs, consistent with repetition or degenerate generation. Filtering to those low-entropy cases reveals gibberish repetition, prompting a root-cause check. The lab then compares production inputs to the original test data and finds a preprocessing mismatch: training data was inverted (to stabilize grayscale training), but production preprocessing didn’t apply the same inversion consistently. The lab concludes that fixing such issues often requires changing the model and training data pipeline to handle real-world input variability—like different background colors and contrast—rather than relying on brittle preprocessing assumptions.

Finally, the lab turns the logged failures into a product roadmap. Common user-driven failure modes include inability to recognize printed text (despite handwritten focus), difficulty with complex spatial layouts (like diagrams rather than paragraphs), missing characters outside the ASCII character set, and poor performance on heterogeneous backgrounds. The overarching lesson is that model quality in real products is determined less by infrastructure tweaks and more by data: richer logging enables discovering unknown unknowns, and those discoveries translate into new data collection, synthesis, and retraining strategies.