Designing Machine Learning Systems: From Problem Framing to Production Operations

1. Introduction

A machine learning (ML) model is a small part of a machine learning system. Sculley et al. observed that in real-world systems only a small fraction of the code is the model itself, and that the surrounding infrastructure for data collection, feature extraction, verification, serving, configuration and monitoring is larger, more complex and a principal source of long-term maintenance cost [1]. Huyen frames the design of such systems as an iterative process in which business objectives, data, models, deployment and monitoring are revisited repeatedly rather than completed in sequence [2]. Surveys of deployment case studies report that practitioners encounter difficulties at every stage of this process, from data management through model learning, verification and deployment, together with cross-cutting concerns of ethics, law, end-user trust and security [3].

This paper reviews the end-to-end design of ML systems from the perspective of November 2026. It is organized around the life cycle of a production system. Section 2 addresses problem framing and the decision of whether to use ML at all. Section 3 sets out system requirements. Section 4 covers data engineering, including labeling, class imbalance and leakage, and Section 5 covers feature engineering. Section 6 discusses training and model selection, Section 7 evaluation metrics, and Section 8 the relationship between offline evaluation and online experiments. Section 9 reviews deployment patterns and Section 10 monitoring and drift. Section 11 addresses MLOps and technical debt, Section 12 responsible documentation, and Section 13 consolidates the discussion in a design checklist. Section 14 concludes. Figure 1 arranges these stages as a loop rather than a sequence: monitoring and retraining feed back into data work, and an evaluation that fails to beat the baseline sends the project back to problem framing.

2. Problem Framing and When Not to Use Machine Learning

Design begins with the decision that the system is meant to support, not with a model. A useful framing specifies who acts on the prediction, what action they take, how quickly the prediction is needed, what an error costs in each direction, and how success will be measured in business terms. Huyen distinguishes business objectives from ML objectives and emphasizes that model metrics are useful only insofar as they move the business metric that motivated the project [2]. The same problem can usually be framed in several ways, for example as classification, regression or ranking, and the framing determines which labels are needed, which loss is optimized and how the output is consumed downstream [2].

Machine learning is appropriate when a task involves patterns that are too complex or too changeable to specify as rules, when examples of the desired behavior exist or can be collected, when the task is repeated often enough for the investment to be recovered, and when occasional errors are tolerable or can be caught [2]. Conversely, ML should be avoided or deferred when a deterministic rule or a simple heuristic meets the requirement, when there is no reliable signal or no way to obtain labels, when errors are unacceptable and cannot be detected, or when the organization cannot support the data pipelines and monitoring that a production model requires. Amershi et al. found at Microsoft that ML components differ from conventional software in the difficulty of data management, the specialized skills needed to customize and reuse models, and the way models become entangled with one another, so that ML imposes engineering costs beyond model training [4]. A non-ML baseline is therefore a design deliverable in its own right: it establishes the value that a model must exceed to justify its complexity.

3. System Requirements

Huyen identifies four requirements that most production ML systems must meet: reliability, scalability, maintainability and adaptability [2]. They are summarized with their principal design implications in Table 1. Reliability is complicated by the fact that ML systems can fail silently: a model that returns well-formed but wrong predictions raises no exception, so correctness must be monitored statistically rather than inferred from uptime [2, 5]. Scalability concerns not only request volume but also the number of models, features and training runs the organization must manage. Maintainability depends on reproducible pipelines, versioned data and code, and clear ownership. Adaptability is the capacity to respond to shifting data distributions and business needs by retraining and redeploying quickly and safely.

4. Data Engineering

4.1 Data Quality and Labeling

Data work frequently determines the outcome of an ML project. Sambasivan et al. interviewed 53 practitioners working on high-stakes AI in India, East and West African countries and the United States and described data cascades, compounding events with negative downstream effects that originate in data issues; they reported a 92% prevalence of such cascades among their participants [9]. Polyzotis et al. survey the data life cycle of production ML, including data understanding, validation, cleaning and preparation, and describe the challenges that arise when these activities must operate continuously on changing production data rather than once on a static dataset [10]. A practical consequence is that data validation belongs in the pipeline itself: each new batch of training or serving data should be checked against an explicit schema covering expected features, types, value ranges and missing-value rates before it reaches a model, so that upstream changes are detected where they occur rather than inferred later from degraded predictions [10, 6].

Labels deserve particular scrutiny because they define what the model learns and how it is judged. Northcutt et al. estimated an average of at least 3.3% label errors in the test sets of ten widely used computer vision, language and audio datasets, including at least 6% of the ImageNet validation set, and showed that such errors can change which model appears best [11]. Confident learning provides a principled method for estimating the joint distribution of noisy and true labels and identifying likely mislabeled examples [12]. Practical labeling programs therefore define written labeling guidelines, measure inter-annotator agreement, audit a sample of labels, and version label sets so that changes in guidelines can be traced to changes in model behavior.

4.2 Class Imbalance

Many operational problems, such as fraud, equipment failure and defect detection, involve a rare positive class. He and Garcia review the effects of imbalance and the main remedies: sampling methods, cost-sensitive learning that assigns higher cost to minority-class errors, and evaluation metrics that remain informative when one class dominates [13]. The synthetic minority over-sampling technique (SMOTE) generates new minority examples by interpolating between a minority example and its nearest minority neighbors rather than duplicating examples [14]. Resampling changes the class prior seen during training, so predicted probabilities must be recalibrated (Section 7.3) before they are used as estimates of real-world risk, and resampling must be applied only to training folds, never to validation or test data.

4.3 Data Leakage

Kaufman et al. define leakage as the introduction of information about the target that should not legitimately be available to the model, and describe it as one of the most common mistakes in data mining practice, illustrated by controversies in several public competitions [15]. Typical sources include features computed after the prediction time, identifiers that encode the outcome, preprocessing statistics computed over the full dataset before splitting, and duplicate or near-duplicate records that appear in both training and test sets. Kaufman et al. propose a learn–predict separation in which each training example is constructed using only data available before its prediction point [15]. For temporal problems this implies time-based splits rather than random splits, and for grouped data, such as multiple records per customer or per machine, it implies splitting by group.

5. Feature Engineering

Feature engineering converts raw data into inputs that a model can use. Even where deep learning learns representations from raw inputs, production systems typically combine learned embeddings with engineered features such as aggregates over time windows, ratios, counts and domain-specific indicators [2]. Common operations include scaling numerical features, encoding categorical features (one-hot, target or hashed encodings), handling missing values explicitly, discretizing continuous variables and constructing interaction terms. Each transformation must be fitted on training data only and then applied unchanged at serving time; fitting a scaler or encoder on the full dataset is a form of leakage [15].

The principal systems risk in feature engineering is training–serving skew, in which features are computed differently in the offline training pipeline and the online serving path. Sculley et al. identify related forms of debt, including unstable and underutilized data dependencies, glue code and "pipeline jungles" of ad hoc preprocessing steps, and they note that because of entanglement, changing any input feature can change the behavior of the whole model, which they summarize as "changing anything changes everything" [1]. Shared feature definitions used by both training and serving, schema validation of inputs, and periodic pruning of features with little marginal value reduce these risks [1, 6].

6. Training and Model Selection

6.1 The Bias–Variance Trade-off

Model selection balances underfitting and overfitting. For squared-error loss, the expected prediction error of an estimator f̂ at input x, with target y = f(x) + ε and noise variance σ², decomposes into three terms [16, 17]:

The first term is the squared bias, the second the variance of the estimator over training sets, and the third the irreducible noise. Geman et al. showed that flexible models such as neural networks reduce bias at the cost of variance, so that controlling variance through regularization, more data or constrained model families is central to generalization [16]. In practice, a simple, well-regularized baseline such as logistic regression or a gradient-boosted tree model should be trained first; it calibrates expectations, exposes data problems early and provides the benchmark against which more complex models are judged [2].

6.2 Cross-Validation and Hyperparameter Selection

K-fold cross-validation estimates generalization error by training on K − 1 folds and evaluating on the held-out fold, rotating through all folds [17]. When the same cross-validation estimate is used both to tune hyperparameters and to report performance, the estimate is optimistically biased; Varma and Simon demonstrated this bias and showed that nested cross-validation, in which tuning is performed inside each outer training fold, yields an approximately unbiased estimate [18]. Splits must respect the structure of the data identified in Section 4.3: time-ordered or grouped splits for temporal or grouped data, and stratification by class for imbalanced problems. A final test set, held out from all development decisions, provides the last offline check before deployment.

7. Evaluation Metrics

7.1 Precision, Recall and F1

For a binary classifier with true positives TP, false positives FP and false negatives FN at a given decision threshold:

Precision is the fraction of positive predictions that are correct, recall the fraction of actual positives that are found, and F₁ their harmonic mean. The appropriate balance depends on the error costs identified during problem framing (Section 2): a screening model that triggers a cheap manual review favors recall, while a model that triggers an expensive or irreversible action favors precision. Because both quantities depend on the threshold, the threshold should be chosen explicitly from the cost trade-off rather than left at a default of 0.5 [19].

7.2 ROC Analysis and Precision–Recall Curves

The receiver operating characteristic (ROC) curve plots the true positive rate against the false positive rate as the threshold varies. The area under the ROC curve (AUC) has a probabilistic interpretation: it equals the probability that the classifier assigns a higher score to a randomly chosen positive instance than to a randomly chosen negative instance [19]:

where s is the classifier's score and x⁺ and x⁻ are positive and negative instances. AUC is threshold-independent and insensitive to class prevalence, which is useful for comparing rankers but can mask poor performance on a rare positive class. Saito and Rehmsmeier showed that precision–recall plots are more informative than ROC plots for evaluating binary classifiers on imbalanced datasets [20]. Table 2 summarizes these and related metrics. Figure 2 illustrates both points on a synthetic data set with 5% positives: ROC-AUC is 0.93, yet precision at the default threshold of 0.5 is only 0.37, and the threshold that minimizes a stated error cost differs from both 0.5 and the F₁-maximizing value.

7.3 Calibration

When predicted probabilities feed decisions, expected costs or downstream models, they must be calibrated, meaning that among instances assigned probability p, approximately a fraction p are positive. Guo et al. found that modern neural networks are poorly calibrated, with depth, width, weight decay and batch normalization affecting calibration, and that temperature scaling, a single-parameter variant of Platt scaling, is effective on most datasets [21]. They measure miscalibration with the expected calibration error (ECE), which partitions n predictions into M confidence bins B_m and compares accuracy with mean confidence in each bin [21]. The Brier score, the mean squared difference between predicted probability p_i and outcome o_i ∈ {0, 1}, combines calibration and discrimination in a single proper scoring rule [22]:

8. Offline Versus Online Evaluation

Offline evaluation on historical data estimates how a model would have performed, but it cannot capture how users and processes react to the model's outputs, nor the feedback loops through which a deployed model alters its own future training data [1]. Online controlled experiments, or A/B tests, randomly assign units such as users or sessions to the existing system or the candidate and compare an overall evaluation criterion (OEC), a quantitative measure of the experiment's objective [23]. Kohavi et al. give a rule of thumb for the minimum sample size per variant at 95% confidence and 90% power:

where r is the number of variants, σ is the standard deviation of the OEC and Δ is the minimum difference to be detected; the authors note that the factor of 4 may overestimate the requirement by about 25% for large n [23]. Because the required sample grows with the inverse square of Δ, detecting small improvements requires large samples or variance-reduction techniques. Kohavi, Tang and Xu discuss the practical conditions for trustworthy experiments, including guardrail metrics, checks that the observed allocation matches the intended allocation, and the dangers of stopping early when results look favorable [24]. Where randomized experiments are infeasible, as in many industrial process applications, shadow deployment, in which the candidate model scores live traffic without affecting decisions, and staged rollouts provide weaker but still valuable evidence [2].

9. Deployment Patterns

Deployment patterns differ mainly in when predictions are computed and where. In batch prediction, the model scores a population on a schedule and writes predictions to a store from which applications read them; this is simple and efficient but cannot react to information that arrives between runs. In online prediction, the model is served behind an interface and scores each request as it arrives, which supports fresh features and personalized responses but imposes latency, availability and scaling requirements [2]. Streaming designs compute features from event streams so that online predictions can use near-real-time information. Edge deployment runs the model on a device or local controller, reducing latency, network dependence and data transfer, but constraining model size and complicating updates and monitoring [2].

Paleyes et al. group deployment-stage challenges into integration, monitoring and updating, and note that integration difficulties often stem from infrastructure, code quality and the need to coordinate ML and software teams [3]. Whatever the pattern, releases should be progressive: shadow mode first, then a canary on a small share of traffic, then wider rollout, each stage gated by predefined metric thresholds and each with a tested rollback path. The ML Test Score rubric of Breck et al. includes corresponding infrastructure tests: model quality is validated before serving, models are canaried before serving, and serving models can be rolled back; its monitoring tests include checks that training and serving are not skewed and that models are not too stale [6].

10. Monitoring and Drift

10.1 Types of Drift

A model trained on one data distribution is deployed into a world that changes. Gama et al. define concept drift as a change in the joint distribution of inputs and targets over time, and distinguish real drift, a change in the conditional distribution p(y | x), from virtual drift, a change in the input distribution p(x) that does not alter the decision boundary; they further characterize drift by its pattern as sudden, incremental, gradual or recurring [8]. Lu et al. review drift detection, understanding and adaptation, and organize detection methods into error-rate-based, data-distribution-based and multiple-hypothesis-test approaches [25]. Rabanser et al. emphasize that ML systems tend to fail silently when inputs shift; in their experiments, two-sample testing on representations produced by a pretrained classifier was the most effective of the shift-detection methods they examined [5].

10.2 Distribution Monitoring with KL Divergence and PSI

Ground-truth labels often arrive late or never, so monitoring relies heavily on input and prediction distributions. The Kullback–Leibler divergence of a current distribution Q from a reference distribution P over bins i is defined as [26]:

The population stability index (PSI), widely used in credit-risk model validation, compares the actual proportion a_i of a variable in bin i with the expected proportion e_i from the development sample. Algebraically, PSI equals the sum of the two directed divergences, D_KL(A ‖ E) + D_KL(E ‖ A), so it is symmetric in the two distributions. Yurdakul and Naranjo note that the conventional rule-of-thumb thresholds of 0.10 and 0.25 are applied without reference to type I or type II error rates, and they study the statistic's sampling properties to support more principled use [27]. Both measures require care with empty bins, which make the logarithm undefined, and with the choice of binning. A monitoring design should combine such distribution statistics with data-quality checks (schema, missing rates, ranges), prediction-distribution monitoring, and, when labels become available, delayed performance metrics; alerts should be tied to retraining or investigation procedures rather than left as dashboards [6, 25]. Figure 3 shows on synthetic data why the threshold should be derived rather than assumed: with 2,000 observations per check, a threshold set from the no-drift sampling distribution of PSI flags a gradual shift at week 6, whereas the 0.10 and 0.25 rules of thumb are first exceeded at weeks 11 and 15.

Once drift is detected, the system must adapt. Gama et al. distinguish informed adaptation, in which retraining is triggered by a detector, from blind adaptation, in which the model is updated at regular intervals regardless of evidence of change, and they review memory and forgetting mechanisms such as sliding windows and instance weighting that determine which historical data remain in the training set [8]. Lu et al. add drift understanding, establishing when, how and where a drift occurred, as a step between detection and adaptation, because the appropriate response to a sudden, localized change differs from the response to a gradual, global one [25]. In production, scheduled retraining provides a simple form of blind adaptation, while detector-triggered retraining reduces unnecessary updates; in either case, each retrained model should pass the same automated evaluation gates as the original before it replaces the serving model [7, 6].

11. MLOps and Technical Debt

11.1 Hidden Technical Debt

Sculley et al. argued that ML systems incur technical debt that is hidden at the system level rather than visible in code. Their catalog includes the erosion of abstraction boundaries through entanglement, correction cascades in which models are stacked to patch one another, undeclared consumers of model outputs, unstable and underutilized data dependencies, direct and hidden feedback loops, system-level anti-patterns such as glue code, pipeline jungles and dead experimental code paths, configuration debt, and changes in the external world [1]. Shankar et al., interviewing 18 ML engineers across applications including chatbots, autonomous vehicles and finance, identified velocity, validation and versioning as the three variables governing success in production deployments [28].

11.2 The ML Test Score

Breck et al. turned production-readiness practice at Google into a rubric of 28 tests in four sections of seven: tests for features and data, tests for model development, tests for ML infrastructure, and monitoring tests. A test earns half a point if performed manually with documented results and one point if automated and run repeatedly; the final ML Test Score is the minimum of the four section scores, so that progress is required in every area [6]. The minimum aggregation is a useful design principle in its own right: an excellent model with no monitoring is not production-ready.

11.3 MLOps Principles

Kreuzberger et al. combined a literature review, a tool review and eight expert interviews to define MLOps as a paradigm, spanning best practices, concepts and a development culture, for the end-to-end conceptualization, implementation, monitoring, deployment and scalability of ML products, drawing on ML, software engineering (especially DevOps) and data engineering [7]. They identify nine principles: CI/CD automation, workflow orchestration, reproducibility, versioning of data, model and code, collaboration, continuous ML training and evaluation, ML metadata tracking and logging, continuous monitoring, and feedback loops [7]. Amershi et al. describe a nine-stage ML workflow integrated into agile software processes at Microsoft, from model requirements and data collection through training, evaluation, deployment and monitoring, and stress that the stages contain feedback loops rather than a linear sequence [4]. The level of automation should be matched to the system's change rate and risk; a model retrained annually may not need continuous training, but every production model needs versioning, reproducibility and monitoring.

12. Responsible ML Documentation

Documentation makes a model's intended use, limitations and evidence available to the people who deploy, operate, audit and are affected by it. Model cards are short documents accompanying trained models that report benchmarked evaluation across relevant conditions and groups, including cultural, demographic, phenotypic and intersectional groups where these are relevant to the application, and that disclose the intended context of use and the evaluation procedures [29]. The proposed sections cover model details, intended use, factors, metrics, evaluation data, training data, quantitative analyses, ethical considerations, and caveats and recommendations [29].

Datasheets for datasets apply the same principle to data. Gebru et al. propose that every dataset be accompanied by a datasheet that documents its motivation, composition, collection process, preprocessing, cleaning and labeling, recommended uses, distribution and maintenance [30]. In industrial and enterprise settings, the same documents serve practical purposes beyond fairness: they record the operating envelope within which a model was validated, the data sources on which it depends, and the conditions under which it should not be used, which are exactly the facts needed during incident investigation and model handover.

13. Design Checklist

Table 3 consolidates the preceding sections into a design checklist organized by life-cycle stage. As with the ML Test Score, the value of the checklist lies in requiring evidence for every stage rather than excellence in one [6].

14. Conclusion

Designing a machine learning system is a systems-engineering task in which the model is one component among data pipelines, feature computation, serving infrastructure, monitoring and governance [1, 2]. The literature reviewed here converges on several principles. Problems should be framed around decisions and error costs, with a non-ML baseline as the benchmark. Data quality, label accuracy and the exclusion of leakage determine the ceiling on model performance [9, 11, 15]. Evaluation should use metrics matched to class balance, error costs and the need for calibrated probabilities, and should be completed by online evidence where possible [20, 21, 24]. Deployed models must be monitored for drift and silent failure [8, 5], and the system as a whole should be assessed for production readiness across data, model, infrastructure and monitoring, with documentation that records its intended use and limits [6, 7, 29, 30]. Systems designed on these principles can be maintained, audited and improved as their data and requirements change.