# Build a Culture of ML Testing and Model Quality

Mohamed Elgendy, Kolena | MLOps Coffee Sessions | Episode 76 | 51:14

Source: https://www.youtube.com/watch?v=2Ln-cVE1W9o
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/build-a-culture-of-ml-testing-and-model-quality
Published: 2022-01-25
Tags: caching, evals, structured-outputs, testing

## TL;DR
- Mohamed Elgendy argues that global metrics such as accuracy and F1 score hide failures in specific scenarios, so teams should evaluate models with fine-grained, versioned test cases.
- Kolena's test-centric development process starts from product specifications, creates test cases, and repeats training and testing until the model meets explicit scenario-level criteria.
- A history of test results can reduce repeated computation while giving teams a shared record of model behavior, failure modes, product requirements, and regressions.

## Summary
Mohamed Elgendy explains why model quality cannot be captured by a single accuracy or F1 score. He draws on work with computer-vision systems, including a gun detector for security applications, where a high aggregate score still hid failures in situations that mattered to customers. His approach starts with product specifications and turns them into fine-grained test cases covering scenarios such as occlusion, orientation, camera conditions, and weather. Teams test models against those cases, record results in an evaluation store, and use regressions to decide whether to collect data, tune the model, or change the approach. Mohamed says this creates an organizational knowledge base that helps new engineers, managers, product teams, and regulated businesses understand model behavior. He also describes how retaining the history of each data sample can reduce unnecessary reruns. The conversation covers adoption, structured and unstructured data, regulation, and Mohamed's book on deep learning for vision systems.

## Key ideas
### A strong global score can hide failures that matter to the product
[05:45](https://www.youtube.com/watch?v=2Ln-cVE1W9o&t=345s)
Mohamed describes building computer-vision algorithms to detect threats in X-ray machines. A statement such as a gun detector being 98 or 99 percent accurate was not enough for security and defense customers. The team needed to say which scenarios the model handled and with what confidence. A model could miss a gun in a case that appeared easy, even while its aggregate metric looked strong. Mohamed says teams should stratify data into real product scenarios and use those scenarios to guide iterative improvement. This changes the question from whether the model is accurate overall to where it fails and whether those failures affect the customer or product objective.

### Model quality depends on managed test data as much as on the model
[10:26](https://www.youtube.com/watch?v=2Ln-cVE1W9o&t=626s)
Mohamed defines model quality as a function of the model and the test data. Training tools have made the model and training process easier to manage, while test data is often treated as a benchmark set that grows without much structure. A full testing workflow includes managing test cases, running inferences, generating reports, comparing models, and saving results in an evaluation store. In computer vision, creating useful scenarios can require relabeling large image collections whenever the team learns more about the domain. Kolena's test-case studio is intended to let teams stratify data and create new scenarios in minutes instead of weeks, then version and manage those cases as the collection grows.

### Test cases become an organizational record of product knowledge
[13:50](https://www.youtube.com/watch?v=2Ln-cVE1W9o&t=830s)
Mohamed says a testing process creates a knowledge base that is more useful than a document hidden in an engineer's head. A car detector might begin with easy, medium, and hard cases. As the team finds problems, it can add cases for orientation, occlusion, camera conditions, and weather. Over time, a small initial set can become hundreds of more precise cases. A new engineer can inspect the cases and the history of model results to learn which customer environments and product specifications matter. Managers can review product features and their regressions instead of only tracking model versions. The record also helps teams decide whether the next action is more data, tuning, or another change.

### Caching evaluation history allows more testing with fewer repeated runs
[18:11](https://www.youtube.com/watch?v=2Ln-cVE1W9o&t=1091s)
Adam asks whether large test sets and many test cases create too much computation and storage cost. Mohamed says Kolena addresses this with an evaluation store that keeps the testing history for each image, video frame, or other data sample. When a model and data sample combination has already been evaluated, the system can avoid running the same inference again. New or changed combinations are tested, while previous results remain available for comparison and reporting. Mohamed says teams may run more tests while spending less computation than before because the platform adds only the relevant data or model runs. He also distinguishes the initial evaluation from later questions that compare models, since many reporting tasks can use results that are already stored.

### Teams adopt testing when it reduces their other sources of work
[21:37](https://www.youtube.com/watch?v=2Ln-cVE1W9o&t=1297s)
Mohamed says quality initiatives usually begin with a technical leader or manager, or after customer problems create pressure on the business and engineering teams. His pitch to data scientists is practical: a systematic test process can reduce training, data collection, labeling, and repeated questions from other teams. In one example, a team increased the number of test runs from once a week to ten times a week while spending fewer hours on testing. Mohamed says adoption depends on making the workflow easy through a platform, a user interface, and integration with existing Python workflows. He avoids calling the approach conventional TDD because machine-learning performance is statistical and requires explicit coverage of the relevant data cases.

### Regulatory requirements can become explicit test specifications
[28:45](https://www.youtube.com/watch?v=2Ln-cVE1W9o&t=1725s)
Mohamed says teams working in regulated domains can turn regulatory requirements into product specifications and test cases. For a face-related system, the relevant cases might include differences by gender, race, or age. Teams can test those cases, identify failure modes, and train against the specifications instead of treating training as a process of guessing what data to add. Once results are stored, the team can produce reports for regulators, auditors, or other organizations. Mohamed mentions NIST as an example of an organization whose reports focus on these kinds of requirements. The testing record therefore supports both engineering decisions and evidence about model behavior.

### Fine-grained test cases expose regressions that a higher accuracy score misses
[31:27](https://www.youtube.com/watch?v=2Ln-cVE1W9o&t=1887s)
Mohamed presents a comparison between two models. One model has a lower aggregate accuracy, while another improves the global score from 96.8 percent to 99 percent. The higher-scoring model still regresses on an easy case, such as detecting a gun in an empty bin, while other scenario-level results reveal changes in occlusion and different views. A single metric would encourage deployment of the 99 percent model because it does not show those tradeoffs. Fine-grained test cases let the team define pass or fail criteria for the scenarios it cares about, compare model versions against those criteria, and block deployment when a relevant case regresses.

### Production bugs should become new tests, and one model need not fit every environment
[37:27](https://www.youtube.com/watch?v=2Ln-cVE1W9o&t=2247s)
Mohamed describes a workflow that starts with product specifications, creates tests, assembles training data, trains a model, and tests again. When a production bug appears, the team adds that bug as a test case and repeats the process. He also argues against forcing one general model to work well for every sensor, customer, and environment. A team may keep several models that perform well in different scenarios, or combine models in an ensemble. Testing can identify which existing model is best for a new customer's conditions, so the team may not need to train a new model every time.

## Notable quotes
- "Model quality is a function of the model and the test data." (10:26)
- "It's not a one-time heroic effort, it's more of a team culture to guarantee that kind of quality level improves by time and being able to measure it and communicate it with everybody." (09:23)
- "You define the target before you take a swing." (38:41)
- "We never deploy without [pass or fail criteria]." (36:02)
- "The idea of having one general model that is great at everything is really painful." (37:50)

## Tools & references mentioned
- Kolena
- Deep Learning for Vision Systems
- Manning
- NIST
- TDD
- test-centric development
- evaluation store
- Great Expectations
- TDDA
- Split.io
- Udacity
- Amazon Machine Learning University

## Who should watch
- Your team relies on accuracy, F1, or another global metric and needs to understand failures across customer or deployment scenarios.
- You are trying to introduce systematic ML testing and need a practical argument for reducing repeated training, labeling, and debugging work.
- Your model operates in a regulated domain and you need test cases, result history, and reports tied to explicit product requirements.

## Editor's note

Mohamed Elgendy argues that a high aggregate score can still hide failures in scenarios that matter to a product. ZenML records each pipeline run's steps, inputs, outputs, and code version, so teams can trace an artifact or model to the data and code that produced it. That record gives model testing a reproducible place in the workflow.

Written by the MLOps Talks editors (the ZenML team), not by the speaker.

## Related talks

- [ML Tests](https://mlopstalks.com/talks/ml-tests) (Svet Penkov, Efemarai, 40:24)
- [The ML Test Score](https://mlopstalks.com/talks/the-ml-test-score) (Skylar Payne, 57:48)
- [ML Stepping Stones: Challenges & Opportunities for Companies](https://mlopstalks.com/talks/ml-stepping-stones-challenges-opportunities-for-companies) (John Crousse, 47:47)
- [Impact of SWE in ML Projects](https://mlopstalks.com/talks/impact-of-swe-in-ml-projects) (Laszlo Sragner & Tim Blazina, 55:42)
- [The Godfather Of MLOps](https://mlopstalks.com/talks/the-godfather-of-mlops) (D. Sculley, Google, 51:25)