# The Godfather Of MLOps

D. Sculley, Google | MLOps Coffee Sessions | Episode 32 | 51:25

Source: https://www.youtube.com/watch?v=cvfTVHlYad8
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/the-godfather-of-mlops
Published: 2021-03-23
Tags: evals, reliability, security, testing

## TL;DR
- MLOps has grown from a small set of practices inside teams into a community with dedicated jobs, podcasts, infrastructure, and platforms.
- 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.
- 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.

## Key ideas
### MLOps has become a real community around problems that used to be hard to discuss
[02:08](https://www.youtube.com/watch?v=cvfTVHlYad8&t=128s)
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
[06:46](https://www.youtube.com/watch?v=cvfTVHlYad8&t=406s)
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
[17:14](https://www.youtube.com/watch?v=cvfTVHlYad8&t=1034s)
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
[13:11](https://www.youtube.com/watch?v=cvfTVHlYad8&t=791s)
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
[23:39](https://www.youtube.com/watch?v=cvfTVHlYad8&t=1419s)
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
[27:24](https://www.youtube.com/watch?v=cvfTVHlYad8&t=1644s)
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
[32:09](https://www.youtube.com/watch?v=cvfTVHlYad8&t=1929s)
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
[43:16](https://www.youtube.com/watch?v=cvfTVHlYad8&t=2596s)
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.

## Notable quotes
- "Model accuracy by itself does not guarantee system level reliability." (03:49)
- "The test score was really written for situations where you don't care about one prediction, you care about millions or billions of predictions per day." (11:10)
- "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)
- "Test until fear turns to boredom." (20:54)
- "Science is what happens when you write stuff down." (48:38)

## Tools & references mentioned
- Google Brain
- MLOps Community
- ML Test Score
- Machine Learning: The High-Interest Credit Card of Technical Debt
- Under Specification
- OpenAI
- ImageNet
- Labelbox
- Superb AI
- federated learning
- secure multi-party computing

## 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.

## Editor's note

D. Sculley says that earlier ML pipelines were one-off projects, with teams building production infrastructure from scratch. ZenML lets teams write workflows as Python steps and run the same pipeline on different infrastructure through configuration. Each run records its steps, inputs, outputs, and code version, so teams can trace a model or artifact back to its sources.

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

## Related talks

- [MLOps Insights](https://mlopstalks.com/talks/mlops-insights) (David Aponte-Demetrios Brinkmann-Vishnu Rachakonda, 37:47)
- [What MLOps Has Taught Me](https://mlopstalks.com/talks/what-mlops-has-taught-me) (Ewan Nicolson, Forecast, 54:14)
- [Practical MLOps Part 2](https://mlopstalks.com/talks/practical-mlops-part-2) (Alfredo Deza, Author and Speaker, 1:01:38)
- [Engineering MLOps](https://mlopstalks.com/talks/engineering-mlops) (Emmanuel Raj, TietoEvry, 51:55)
- [Practical MLOps](https://mlopstalks.com/talks/practical-mlops) (Noah Gift, Pragmatic AI Labs, 58:36)