Complexity in Machine Learning Systems
Production systems have different requirements from one-off analysis scripts, including reliability, predictability, runtime, and memory.
From One Result to a Running System
Imagine you have trained a machine learning algorithm that produces good predictions on a dataset you downloaded for a one-off analysis. The results are useful, you write them up, and the work is finished. Now imagine the same algorithm must be placed inside a larger software system that runs every day, serves many users, and has to keep working as the data around it changes. The question is no longer only whether the algorithm is accurate. It becomes whether the whole system behaves well over time.
This shift is the subject of this article. It introduces technical debt in machine learning, a way of describing the trade-offs that appear when machine learning software is developed and maintained in production. Before reading on, consider a question about who this applies to.
What do you think happens?
Does the lesson about technical debt only matter for large, long-lived projects?
Reveal answer
No, the lessons also apply to small and short-lived systems.
The source says the idea is most pressing for large, long-lived projects, but the lessons learned can also help build better software for short-lived and smaller systems. Simplicity is described as key to machine learning systems that perform well in production, and that applies to small projects too.
Why Production Changes the Requirements
The source makes a basic point: production systems have different requirements from one-off analysis scripts. A script can be run once, inspected by its author, and thrown away. A deployed algorithm is part of something bigger, so software engineering concerns move to the front. The diagram below sets the two situations side by side.
The source names four requirements that move to the front once a system is in production. They are reliability, predictability, runtime, and memory requirements. A one-off script can be judged mainly on whether its output is useful. A production system must also be judged on these four concerns, because it keeps running after its author has moved on.
- Reliability: the system must keep behaving well over time
- Predictability: the system's behavior must be dependable enough to be relied on
- Runtime requirements: the time the system needs to run must be acceptable in a deployed setting
- Memory requirements: the memory the system needs must be acceptable in a deployed setting
Technical Debt as a Trade-Off
Technical debt in machine learning is the trade-off made when developing and maintaining machine learning software in production, especially at large scale.
The word trade-off is the key. Every part added to a pipeline brings some complexity with it. Sometimes that complexity is worth it, and sometimes it is a burden that must be maintained later. The source frames this as a practical way of describing choices made during creation and maintenance, not as a formula you can compute.
Three Questions for Every Pipeline Component
The source gives a practical method rather than a formula. It asks you to critically inspect each part of your data processing and prediction pipeline and to answer three questions about it. Each question is applied to one component at a time. The diagram shows the idea: every stage of the pipeline is checked against the same three questions.
Tracing a Proposed Component Through the Questions
The following scenario is an original illustration of the source's method. It is not taken from the source. Suppose a team has a prediction pipeline with two stages: a data processing stage that prepares inputs, and a prediction stage that produces outputs. A colleague proposes adding a new data processing step that combines several intermediate transformations into one custom component. The team applies the three questions to this proposal.
Should the combined custom component stay?
A colleague proposes replacing several intermediate transformations in the data processing stage with one custom component. Decide whether this component earns its place in the production pipeline.
- 1Ask about complexity
Several separate steps become one custom component. Every step in the pipeline adds complexity, and folding several steps into one custom piece means the logic inside it must be understood and maintained as a unit. Record this as a real cost.
- 2Ask about robustness
Consider what happens if the data arriving at the data processing stage changes, or if the infrastructure it runs on changes. The team checks whether the custom component keeps behaving reliably in those situations. Record any weak points, such as assumptions about the form of the input.
- 3Ask about benefit
The team compares what the combined component delivers against the complexity and fragility noted in the first two questions. If the benefit is large, the component can be justified even though it is complicated. If the benefit is small, it is a candidate for simplification or removal.
The outcome depends on the benefit question. A complicated, fragile component is kept only when its benefit is enough to justify that cost; otherwise the team simplifies it or removes it.
Mistakes When Judging Pipeline Complexity
Common mistake Judging a pipeline component only by whether its output is accurate
Why it failsThe source's shift is from asking whether the algorithm is accurate to asking whether the whole system behaves well over time. Accuracy is only one part of that picture.
Do this insteadAsk all three questions about each component: complexity, robustness, and benefit.
Common mistake Treating every added step as free
Why it failsThe source says every step in the data processing and prediction pipeline adds some amount of complexity, and that amount is crucial to overall performance.
Do this insteadRecord the complexity each component adds before deciding whether to keep it.
Common mistake Assuming a component is safe because it works on today's data
Why it failsRobustness concerns what happens when the data a component receives or the infrastructure it runs on changes. Current success does not show that.
Do this insteadCheck how the component behaves under changes to its inputs and infrastructure.
Common mistake Removing a component the moment it is found to be complicated
Why it failsThe source says a component can be complicated and fragile yet still justified if it delivers enough benefit.
Do this insteadLet the benefit question decide, comparing the benefit against the complexity and fragility.
Common mistake Thinking these lessons are only for large projects
Why it failsThe source says the issue is most pressing for large-scale and long-term projects, but the lessons also help smaller and short-lived systems.
Do this insteadApply the three questions to small projects too, in proportion to their size.
Keeping Small Projects Simple
The source states that simplicity is key to machine learning systems that perform well in production, and that its lessons apply to small and short-lived projects too. The source does not say that smaller projects can ignore technical debt. Instead, it says the lessons learned can help build better software even for short-lived and smaller systems.
For any proposed part of a pipeline, however small the project, ask the three questions in order of your concern: how much complexity it adds, whether it keeps working when data or infrastructure changes, and whether its benefit is large enough to justify both.
Practice Deciding on a Component
A team's prediction pipeline has a data processing stage and a prediction stage. A colleague proposes a hand-written step that reshapes the input data in a special way to gain a small improvement in one measure. Using the three questions, decide whether this step should stay in the production pipeline. Explain your decision by addressing complexity, robustness, and benefit in turn.
Hints
- Start with complexity: what does the hand-written step add to the pipeline that someone must understand and maintain?
- For robustness, ask what happens to the step if the incoming data changes shape or the infrastructure it runs on changes.
- For benefit, compare the small improvement against the complexity and fragility you identified. The final decision rests on that comparison.
Wrapping Up the Production Shift
Moving from a one-off analysis to a deployed system changes the questions you ask. Accuracy remains important, but reliability, predictability, runtime, and memory move to the front, and each part of the pipeline must be judged by its complexity, its robustness, and whether its benefit justifies that cost.
Key Takeaways
- A production system has different requirements from a one-off analysis script, including reliability, predictability, runtime, and memory.
- Technical debt in machine learning is the trade-off made when developing and maintaining machine learning software in production, especially at large scale.
- Each part of a pipeline should be checked for the complexity it creates, its robustness to changes in data or compute infrastructure, and whether its benefit warrants that complexity.
- A complicated or fragile component can still be justified if its benefit is large enough; otherwise it is a candidate for simplification or removal.
- Simplicity is key to machine learning systems that perform well in production, and the lessons apply to small and short-lived projects too.