MLOps has grown from a small set of practices inside teams into a community with dedicated jobs, podcasts, infrastructure, and platforms.
2
The ML Test Score is a process for asking whether important production questions have good answers, not a pass-fail score enforced by an imagined ML police force.
3
As models, data sets, deployment targets, and devices expand, teams need stress tests for domain shift, counterfactual changes, security, and model behavior at its limits.
Summary
D. Sculley reflects on how machine learning operations has changed since his papers on technical debt and the ML Test Score. The field now has a visible community, dedicated jobs, and platforms that can provide more of the infrastructure that teams once had to build as one-off systems. He explains that model accuracy does not guarantee system reliability, especially when production data differs from training data. The ML Test Score is meant to prompt careful questions rather than impose a fixed target. Sculley argues for testing sliced data, shifted data, counterfactual examples, model limits, and every deployment path. He also discusses under-specification, where models can perform similarly on ordinary test data while behaving very differently on edge cases. Looking ahead, he expects larger models, federated learning, more devices, and more security work to increase the need for practical testing and operational abstractions.
MLOps has become a real community around problems that used to be hard to discuss
Sculley says the world around machine learning has changed dramatically in the past four to six years. There are more people building ML systems, more people working on infrastructure, and an MLOps Community that shares practical experience. His earlier papers tried to codify problems that Google teams had encountered but that were not well covered in traditional publications. He now sees much wider recognition that system-level reliability differs from model accuracy. Accuracy matters, but it cannot guarantee that a larger production system will behave reliably. Dedicated MLOps jobs and podcasts also show how different the field is from five or six years earlier.
Production infrastructure has moved beyond one-off machine learning pipelines
In the earlier period Sculley describes, every ML pipeline was a one-off project. Some were well engineered because teams had maintained them for years, but there was little general infrastructure offering integrated solutions. That has changed. Cloud platforms and other systems now attempt to provide production pipelines with built-in ways to address issues raised in the technical debt paper and the ML Test Score. Sculley avoids calling these platforms turnkey, but he considers their availability a major advance. Teams can start with more support for reliability and operational concerns instead of constructing every part from scratch.
The ML Test Score is a set of questions, not a score enforced by rules
Sculley agrees that high-stakes domains such as drug discovery may need human review and may not benefit from automating every step. The ML Test Score was aimed mainly at systems producing millions or billions of predictions, where checking every individual output is impossible. He says the checklist should guide a process of asking important questions and finding good answers. A good answer may reveal a problem to fix, confirm that a control is in place, or explain why a test is unnecessary for a particular system. The point is not to reach a magic score. In one example, using the checklist exposed gaps in data transformations and input schema coverage, which led to concrete work.
Testing must include bias, slices, shifted data, and counterfactual examples
Sculley says the ML Test Score introduced inclusion and bias testing only briefly, while later work has expanded those subjects considerably. He still recommends breaking aggregate metrics into slices such as countries or other problem-specific categories. Teams should also test domain shift, where deployed data differs from training data. Examples include geographic changes, iPhone versus Android images, or objects that are rotated instead of centered. Counterfactual testing changes a small part of an example and checks whether the output changes appropriately, such as switching a sentence from 'the doctor did his thing' to 'the doctor did her thing.' These tests expose behavior that a single accuracy number can hide.
Stress tests require domain knowledge because ML behavior is hard to specify in advance
For the under-specification paper, Sculley's group worked with domain experts across several areas to identify meaningful stress tests and causal relationships that should remain intact. He does not claim this is a complete solution. He would like tools that encode expert knowledge, perhaps through a knowledge graph, and turn it into useful tests. For now, the process remains problem-specific. His reason is fundamental: machine learning is used where teams cannot specify the desired behavior with traditional code. When the behavior cannot be fully specified in advance, testing whether the system has the intended behavior is inherently difficult.
Under-specification makes out-of-distribution repeatability much weaker
Sculley explains that deep learning results can look quite repeatable on ordinary IID train and test splits. The under-specification work examined what happens on stress tests from slightly different distributions. The researchers changed only the random seed while leaving the rest of training constant, then observed substantial variation on perturbed ImageNet data and genomics tasks. In some cases, the variation across random seeds was larger than the difference between a good and a poor model in a machine learning competition. Model ensembles can improve robustness under domain shift, although they add inference cost and system complexity. The practical lesson is to evaluate models on out-of-domain stress tests before deployment.
Larger models and more deployment targets increase the testing burden
Sculley expects models to continue getting larger because additional data and parameters expose more rare and atypical cases rather than merely improving performance on common examples. That creates more opportunities for unexpected behavior, so the need for stress testing grows with scale. He also points to the growing number of deployment paths, including cloud systems, mobile devices, browsers, CPUs, and specialized hardware. Each path needs its own testing. Supporting many combinations creates a combinatorial integration-testing problem. His advice for triage is to test the most important paths first, while accepting that reliability demands more testing than teams may prefer. He quotes a Google phrase: 'test until fear turns to boredom.'
Security and filtering belong in the ML system around the model
Looking again at the diagram from his technical debt paper, Sculley notices missing concerns around security and model outputs. Systems may need spam filtering, protection against bad actors in feedback pipelines, and checks before model outputs enter production. Chatbots are an example where raw outputs may need filtering. These surrounding components can accumulate technical debt and become difficult to change or tied to a specific model version. He expects security, input controls, output filtering, and related infrastructure to develop into larger areas of practice. The work is broader than choosing an algorithm because the environment around the model can change its risks.
"It's really about the process of asking the questions, making sure that each of the important questions that you're asking yourself that you have a good answer to."12:18
Who should watch
You are maintaining an ML system and need a practical way to find reliability work beyond model accuracy.
Your team is deciding how much to automate in a high-stakes domain where human review still matters.
You are deploying models across changing data sources, devices, or platforms and need ideas for stress and integration testing.
