Scalable ML Systems and MLOpsIntroductionA machine-learning model becomes valuable only when it can be used reliably in a real environment. Training a model in a notebook is primarily an experimental activity; operating that model for thousands of users, millions of records, or continuously changing data is a systems-engineering problem. Production machine learning combines statistical modelling, software engineering, data engineering, cloud infrastructure, security, and organizational governance. MLOps is the set of practices, technologies, and responsibilities used to develop, deploy, monitor, reproduce, and retire machine-learning systems. It extends DevOps to account for data, features, model artefacts, experiments, stochastic training, changing populations, and model performance that may degrade without any software defect. A scalable ML system must answer several questions: - Which data and code produced a particular model?
- Can the model be reproduced or rolled back?
- Can training and inference handle increasing demand?
- How are data quality, latency, fairness, and prediction quality monitored?
- What happens when data distributions or business conditions change?
- Who is responsible for approving, operating, and retiring the model?
This chapter presents an end-to-end framework for answering these questions. Learning ObjectivesAfter studying this chapter, a learner should be able to: - Design a reproducible ML pipeline using data, code, feature, and model versioning.
- Select suitable batch, online, streaming, cloud, and distributed-computing architectures.
- Package models with containers and expose them through reliable APIs.
- Apply automated testing, continuous integration, continuous delivery, and controlled deployment.
- Explain the role of feature stores and prevent training–serving skew.
- Design monitoring for system health, data quality, model performance, drift, and fairness.
- Define retraining policies, rollback procedures, governance controls, and model-lifecycle stages.
- Evaluate operational, economic, ethical, and regulatory trade-offs in production ML.
1. From Model Development to ML SystemsA production ML system is more than a model. Its principal components are: | Component | Purpose |
|---|
| Data sources | Supply historical and real-time observations | | Data pipeline | Ingest, validate, transform, and store data | | Feature computation | Construct variables used by training and prediction | | Training pipeline | Fit, evaluate, and register models | | Model registry | Store approved model versions and metadata | | Serving layer | Generate predictions in batch, online, or streaming mode | | Monitoring | Detect failures, degradation, drift, and abnormal usage | | Governance | Control access, approvals, documentation, and auditability |
The system may contain several interacting feedback loops. New data supports retraining; monitoring identifies problems; human review may approve or reject a candidate model; and business outcomes may reveal that the prediction target or decision policy has changed. A useful distinction is between model correctness and system correctness. Model correctness concerns whether the algorithm produces valid predictions under defined assumptions. System correctness additionally concerns data freshness, feature availability, serialization, latency, concurrency, security, deployment configuration, and operational recovery. Batch, online, and streaming inferenceIn batch inference, predictions are generated periodically for a defined dataset. It is appropriate for weekly demand forecasts, monthly risk reviews, or recommendation tables refreshed overnight. It generally has lower infrastructure complexity and can exploit large computational jobs. Online inference produces a response to an individual request, often through HTTP or gRPC. It is appropriate for fraud screening or real-time recommendation. The design must specify latency targets, availability, request schemas, timeouts, and behavior when a feature or dependency is unavailable. Streaming inference processes events continuously. It is useful when predictions must react to transactions, sensors, or user activity. Streaming systems require event-time handling, ordering policies, late-event treatment, checkpointing, and recovery from partial failure. The choice should be driven by decision latency, data arrival patterns, cost, consistency requirements, and the consequences of stale predictions—not by a presumption that online inference is always superior. 2. Reproducibility and VersioningReproducibility means that a result can be regenerated, or at least explained and traced, from recorded inputs and procedures. A model version should be associated with: - source-code commit;
- training-data snapshot or immutable data reference;
- feature definitions and feature-data version;
- dependency and operating-system versions;
- hyperparameters and random seeds;
- training and evaluation metrics;
- model artefact checksum;
- responsible persons, timestamps, and approval status.
Data versioningData versioning is more difficult than code versioning because datasets are large, mutable, distributed, and subject to privacy restrictions. A robust design separates immutable raw data from derived datasets. Raw objects may be stored in an object store, while metadata records schema, lineage, partition, retention, and access policy. A data snapshot is not necessarily a perfect copy of every source record. It may be a logical definition such as “all transactions available before time T,” together with source-system versions and extraction rules. This distinction matters when source systems are corrected retroactively. Data validation should check schema, type, null rates, allowed ranges, uniqueness, referential integrity, freshness, and distributional summaries. Validation failures should either stop the pipeline or route data to quarantine, depending on the severity and documented policy. Model registries and promotionA model registry provides a controlled record of model versions. Typical lifecycle states include development, validation, staging, production, and retired. Registration should not imply approval. Promotion should require evidence such as evaluation on a fixed test set, comparison with the incumbent model, fairness checks, security review, and operational tests. A model artefact should be immutable after registration. If a defect is found, a new version should be created rather than silently replacing the old one. This supports auditability and rollback. Experiment trackingExperiment tracking records parameters, metrics, data references, artefacts, and environmental information. It prevents a common failure mode in which a team remembers that a model performed well but cannot identify the exact preprocessing or data sample that produced it. Random seeds improve repeatability but do not guarantee bit-for-bit identity across hardware, distributed execution, libraries, or nondeterministic kernels. Therefore, reproducibility claims should state their scope and tolerance. 3. Pipeline Architecture and Distributed ComputingA production pipeline commonly contains the following stages: - Ingestion from databases, files, message queues, or APIs.
- Validation and schema enforcement.
- Cleaning and transformation.
- Feature generation.
- Dataset splitting without temporal or entity leakage.
- Training and hyperparameter selection.
- Evaluation against statistical and business criteria.
- Registration and approval.
- Deployment and monitoring.
Dependencies should be represented as a directed acyclic graph (DAG), in which each task executes after its inputs are available. DAG scheduling supports retries, partial reruns, lineage, and backfills. A pipeline should be idempotent: rerunning the same logical interval should not create duplicate or inconsistent outputs. Scaling dimensions- Vertical scaling increases CPU, memory, or accelerator capacity on one machine.
- Horizontal scaling adds machines or service replicas.
- Data parallelism partitions training examples across workers.
- Model parallelism partitions a large model across devices.
- Pipeline parallelism overlaps different computation stages.
Distributed computation introduces communication overhead, serialization cost, network bottlenecks, synchronization delays, and failure probability. A distributed job is not automatically faster. If a task has total useful computation W, communication cost C, and coordination overhead O, its practical execution time is influenced by W + C + O; adding workers may reduce W while increasing C and O. For data-parallel training, each worker commonly computes gradients on a mini-batch and participates in gradient aggregation. The effective batch size is approximately Beff = n × B where n is the number of workers and B is the per-worker batch size. This relationship assumes each worker processes B examples per update and that updates are synchronized. It does not imply that optimization behaviour remains unchanged: learning-rate schedules, generalization, memory, and communication cost may change with B_eff. Cloud platforms provide elastic compute, managed storage, networking, identity, orchestration, and observability. However, elasticity does not eliminate design decisions. Teams must manage data egress, regional availability, confidential data, vendor dependence, quota limits, cost controls, and failure recovery. 4. Containers, APIs, and ServingA container packages application code, dependencies, configuration defaults, and runtime assumptions into a deployable unit. It improves consistency between development, testing, and production, but it is not a complete security boundary or a replacement for architecture. A production image should be small, reproducibly built, scanned for vulnerabilities, run as a non-privileged user where possible, and avoid embedding secrets. Dependencies should be pinned or constrained, and the image should be identified by an immutable digest rather than only a mutable tag. Prediction APIsAn online prediction API should define: - request and response schemas;
- feature names, types, units, and permissible ranges;
- authentication and authorization;
- timeout and retry behaviour;
- error codes and fallback behaviour;
- model version returned in response metadata or logs;
- rate limits and maximum payload size.
Retries require care. A client retry may duplicate a request or overload an already failing service. Idempotency keys, bounded exponential backoff, circuit breakers, and explicit timeout budgets are preferable to unlimited retries. Latency is often summarized by percentiles rather than averages. The p95 latency is the value below which 95% of observed requests complete. A service can have a satisfactory average while its p99 latency violates user requirements. Measurement should include preprocessing, model computation, postprocessing, network time, and downstream dependencies. A serving design may use a synchronous model server, an asynchronous queue, a batch endpoint, or a hybrid. Model caching, autoscaling, hardware acceleration, and request batching can improve throughput, but batching may increase individual-request latency. The appropriate choice depends on the service-level objective. 5. Feature Stores and Feature ManagementA feature store manages reusable feature definitions and often provides both an offline store for training and an online store for low-latency serving. It addresses duplication, inconsistent transformations, feature discovery, ownership, freshness, and point-in-time correctness. The central risk is training–serving skew: the feature calculated during training differs from the feature calculated during production inference. Reusing feature definitions, shared transformation code, or a common feature computation framework reduces this risk. A second risk is temporal leakage. A training example must use only information available at its prediction time. For an entity e and prediction time t, a feature value should be selected from records whose event time is not later than t, subject to the feature’s availability delay. Joining with future information can produce impressive offline scores and poor production performance. Feature metadata should include owner, definition, data type, unit, permitted range, freshness expectation, source, transformation logic, privacy classification, and deprecation status. Features containing personal or sensitive information require access controls, minimization, retention limits, and purpose limitation. 6. Automated Testing and CI/CDTesting must cover both software and statistical behaviour. Test categories- Unit tests verify individual transformations and functions.
- Schema tests verify column names, types, constraints, and compatibility.
- Data-quality tests detect null, range, uniqueness, and distribution problems.
- Integration tests verify interaction among storage, feature computation, and serving.
- Contract tests confirm that producers and consumers agree on interfaces.
- Model tests verify output shape, numerical stability, calibration where relevant, and behaviour on known cases.
- Performance tests measure throughput, latency, memory, and concurrency.
- Security tests inspect access control, dependency vulnerabilities, injection risks, and secret handling.
- Regression tests compare a candidate model with an approved baseline.
A model test should not assert that every prediction equals a fixed value when the algorithm is legitimately stochastic. It may instead assert metric tolerances, invariant properties, deterministic seeds within a supported environment, and acceptable changes on a reference dataset. Continuous integration (CI) automatically builds and tests changes. Continuous delivery (CD) keeps a deployable artefact ready, whereas continuous deployment automatically releases changes after required gates. In ML, automatic deployment should be conditional on data, model, operational, and governance checks. A common promotion pattern is: - Build a versioned image and model artefact.
- Run unit, data, security, and integration tests.
- Evaluate on frozen validation and recent holdout data.
- Deploy to a staging environment.
- Perform load and contract tests.
- Release using canary or blue–green deployment.
- Compare live metrics with the incumbent.
- Promote, pause, or roll back.
Canary deployment sends a small fraction of traffic to the new version. Blue–green deployment maintains two environments and switches traffic between them. Shadow deployment sends copied traffic to a candidate without using its predictions for decisions. Shadowing is useful for observing latency and predictions before exposure to users. 7. Monitoring, Drift, and ReliabilityMonitoring should answer four different questions: - Is the service functioning?
- Is the input data valid and timely?
- Are predictions behaving as expected?
- Does the model create useful and fair outcomes?
System monitoringImportant system indicators include availability, request rate, error rate, timeout rate, CPU and memory utilization, queue depth, accelerator utilization, and latency percentiles. A service-level objective (SLO) defines a target, such as a maximum error rate or a latency percentile over a specified period. Data monitoringInput monitoring includes schema changes, missingness, cardinality, ranges, freshness, duplicate records, and unexpected categories. A model may remain available while receiving meaningless inputs; therefore, operational uptime alone is insufficient. Distribution driftLet p(x) be the reference distribution and q(x) the current distribution of a feature or population. A common divergence measure is the Kullback–Leibler divergence: DKL(p ∥ q) = ∑x p(x) log(p(x) ÷ q(x)) For continuous variables, the sum is replaced by an integral. The distributions must be defined on a common support, and q(x) must be positive wherever p(x) is positive; otherwise the divergence may be undefined or infinite. In practice, continuous data are often binned or estimated using density methods. KL divergence is asymmetric and is not, by itself, a universal drift decision rule. The population stability index is another operational measure based on bins: PSI = ∑i (qi − pi) ln(qi ÷ pi) Here p_i and q_i are reference and current proportions in bin i, with positive proportions. Thresholds are context-dependent and should be calibrated rather than treated as scientific laws. Performance monitoringLabels often arrive later than predictions. Once outcomes are available, teams can monitor accuracy, precision, recall, calibration, ranking quality, cost-weighted loss, and subgroup performance. If the positive class is rare, accuracy may be misleading. For a binary classifier: Precision = TP ÷ (TP + FP) Recall = TP ÷ (TP + FN) TP, FP, and FN denote true positives, false positives, and false negatives. These measures require a selected classification threshold and should be interpreted with the business costs of errors. Concept drift and data driftData drift concerns changes in inputs. Concept drift concerns changes in the relationship between inputs and outcomes, often represented as a change in P(y|x). A system can have stable input distributions but declining predictive validity because customer behaviour, policy, or the environment has changed. Monitoring should use alert severity, ownership, runbooks, and escalation. Alerts without an action plan create fatigue. A drift signal should initiate investigation, not automatically trigger retraining in every case. 8. Retraining and Model Lifecycle ManagementRetraining policies may be: - schedule-based, such as monthly;
- event-based, such as after a detected schema or drift event;
- performance-based, such as after a sustained decline;
- demand-based, such as when a new region or product is introduced.
Automatic retraining is safe only when data selection, validation, approval, and rollback are automated and governed. Otherwise it can amplify corrupted data, feedback loops, or adversarial behaviour. A retraining decision should consider: - statistical evidence of degradation;
- business impact and error asymmetry;
- label delay and label quality;
- data representativeness;
- fairness and subgroup effects;
- computational and operational cost;
- whether the target itself remains appropriate.
Lifecycle stages normally include ideation, development, validation, staging, production, maintenance, and retirement. Retirement requires replacing dependencies, preserving records, deleting or archiving artefacts according to policy, and communicating the change to affected stakeholders. Rollback should be tested before it is needed. A rollback may involve switching a model pointer, restoring a container image, reverting feature definitions, or replaying a prior pipeline. It is not sufficient to retain the model file if the former feature logic or runtime environment is unavailable. 9. Governance, Security, and Responsible OperationProduction ML can affect employment, credit, health, safety, access to services, and personal privacy. Governance should therefore be integrated into engineering rather than added at the end. Important controls include: - documented purpose and intended population;
- data-provenance and consent records where applicable;
- role-based access and least privilege;
- encryption in transit and at rest;
- secrets management and key rotation;
- audit logs that resist unauthorized alteration;
- retention and deletion procedures;
- human oversight for high-impact decisions;
- incident response and notification procedures;
- model cards, data documentation, and limitations;
- bias and subgroup-performance assessment.
Fairness cannot be reduced to a single universal metric. Different criteria may conflict when base rates differ, and a technically accurate model can still produce unacceptable effects because of the decision threshold, access policy, or surrounding workflow. Teams should specify the relevant harm, affected groups, legal obligations, and remediation process. Security threats include data poisoning, model extraction, prompt or input manipulation, membership inference, supply-chain compromise, and unauthorized model access. Threat modelling should cover the full pipeline, including training data, registries, build systems, endpoints, logs, and monitoring infrastructure. 10. Cost and Architectural Trade-offsAn architecture should be evaluated by total cost of ownership rather than compute price alone. Relevant costs include storage, training, inference, network transfer, observability, engineering labour, incident response, compliance, and opportunity cost. Online serving may reduce decision latency but require highly available infrastructure and duplicated feature computation. Batch processing may be cheaper and simpler but cannot support immediate decisions. Larger models may improve quality while increasing latency, energy use, and operational risk. Managed cloud services may accelerate delivery while increasing vendor dependence and recurring cost. Capacity planning should use measured workload. If arrival rate is λ requests per second and average service time is S seconds, a basic utilization estimate for one equivalent server is: ρ = λ × S This estimate assumes stable average rates and is not a complete queueing model. As ρ approaches 1, waiting times can grow sharply, and real systems require headroom for bursts, failures, and variability. Thus, capacity should not be set merely equal to average demand. 11. Contemporary DevelopmentsModern ML platforms increasingly support feature lineage, model registries, policy-as-code, automated evaluation, GPU scheduling, and event-driven pipelines. Kubernetes-like orchestration can provide scheduling and service recovery, while workflow engines coordinate data and training jobs. Infrastructure-as-code makes environments reviewable and reproducible. Large foundation models introduce additional concerns: prompt and retrieval versioning, evaluation sets, token-cost monitoring, vector-index freshness, content safety, model-provider dependency, and the distinction between retrieved evidence and generated text. The same MLOps principles remain applicable: version inputs, test interfaces, monitor outcomes, control access, and define rollback or fallback behaviour. Research and industry increasingly emphasize platform engineering: reusable templates, standardized pipelines, self-service deployment, and centrally managed controls. This can improve productivity, but excessive standardization may constrain legitimate experimentation. A mature platform provides paved paths while allowing documented exceptions. 12. Illustrative Case: Demand Forecasting for a Retail NetworkBackgroundA retailer forecasts daily demand for 20,000 product–store combinations. Forecasts determine replenishment quantities. Stockouts reduce revenue, while excess inventory increases holding and markdown costs. ProblemThe existing process runs a monthly script on manually exported data. It lacks data lineage, cannot distinguish a changed product definition from a real demand change, and provides no alert when forecasts deteriorate. A new system must support daily batch inference and weekly retraining. AnalysisThe team identifies sales, promotions, price, holidays, inventory, store attributes, and product lifecycle status as candidate sources. It discovers that cancelled orders were sometimes included in historical demand and that future promotion information was accidentally used for some training rows. The team therefore defines an event-time policy and constructs point-in-time-correct features. The business chooses weighted error costs: under-forecasting is more expensive for high-margin products, while over-forecasting is more expensive for perishables. Evaluation therefore includes a business-weighted loss in addition to standard forecast metrics. The incumbent method is retained as a baseline. Approach and solutionRaw source tables are stored immutably with extraction timestamps. A validation pipeline checks schema, duplicate keys, negative quantities, missing product identifiers, and freshness. Feature definitions are registered with owners and expected update intervals. The offline feature store creates training datasets using only information available before each forecast date; the online store is unnecessary because inference is batch-based. Training runs in a container with a pinned dependency environment. Each run records the code commit, data snapshot, feature definitions, parameters, metrics, and model checksum. Candidate models must outperform the incumbent on a recent holdout period, satisfy subgroup checks by store type, and pass data-quality and performance tests. The pipeline produces daily predictions to a controlled table. A model registry identifies the production version, while the previous version remains available for rollback. Monitoring reports pipeline success, data freshness, missingness, forecast error after sales labels arrive, and drift in promotion and product-lifecycle features. Retraining occurs weekly only when the data-quality gate passes; a severe anomaly pauses promotion and alerts the data owner. OutcomeThe retailer gains reproducible forecasts, traceable data lineage, and a tested rollback path. The most important improvement is not simply a lower validation error; it is the ability to detect faulty inputs before replenishment decisions are generated. The organization also discovers that some forecast errors arise from inventory constraints rather than model quality, leading to a separate improvement in stock-availability data. Learning points- Point-in-time correctness is essential in temporal prediction.
- A baseline and business-weighted evaluation are more informative than one generic metric.
- Monitoring must include data and business outcomes, not only job completion.
- Retraining should be conditional on validated evidence.
- Operational traceability is part of model quality.
Challenges and LimitationsNo MLOps architecture eliminates uncertainty. Labels may be delayed, biased, or unavailable. Drift metrics can produce false alarms or miss changes in conditional relationships. Automated retraining can create feedback loops when model decisions influence the data later used for training. Distributed systems add operational complexity and can make reproducibility harder. Feature stores can become centralized bottlenecks if ownership and interfaces are poorly designed. There is also a risk of measuring what is easy rather than what matters. High availability does not guarantee beneficial decisions; a lower aggregate error may conceal harm to a subgroup; and an impressive benchmark may not represent deployment conditions. Human review, domain knowledge, causal reasoning, and post-deployment evaluation remain necessary. Best-Practice Checklist- Define the prediction task, decision owner, population, and harm model.
- Version data, code, features, environments, and model artefacts.
- Enforce point-in-time correctness and prevent leakage.
- Build validation and rollback before production launch.
- Test schemas, transformations, APIs, security, performance, and model behaviour.
- Monitor system, data, prediction, outcome, and subgroup metrics.
- Use alerts with owners, severity levels, and runbooks.
- Treat drift as an investigation signal, not automatic proof of failure.
- Gate retraining on data quality, evaluation, governance, and operational checks.
- Document limitations and retire models deliberately.
Chapter SummaryScalable ML systems connect data engineering, statistical modelling, software delivery, infrastructure, and governance. Reproducibility depends on versioning data, code, features, environments, experiments, and model artefacts. Production pipelines should be represented as reliable, idempotent workflows and should select batch, online, or streaming inference according to decision requirements. Containers improve deployment consistency, while APIs require explicit contracts, security, timeout, latency, and fallback policies. Feature stores can promote reuse and reduce training–serving skew, but point-in-time correctness is essential. CI/CD for ML must test software, data, models, security, and operational performance before controlled promotion. Monitoring covers service health, data quality, distribution drift, concept drift, model performance, and fairness. Retraining should be evidence-based and governed, with tested rollback and retirement procedures. Finally, responsible MLOps treats privacy, security, explainability, human oversight, and subgroup impact as lifecycle concerns rather than afterthoughts. Key TermsMLOps: Practices for developing, deploying, monitoring, and governing machine-learning systems. Data versioning: Recording immutable or logically reproducible versions of datasets and their metadata. Model registry: A controlled repository of model artefacts, metadata, versions, and approval states. Reproducibility: Ability to regenerate or trace a result from recorded inputs and procedures. DAG: Directed acyclic graph representing dependencies among pipeline tasks. Idempotence: Property that repeating an operation produces the same intended result without harmful duplication. Batch inference: Generating predictions for a collection of records on a schedule. Online inference: Producing a prediction in response to an individual request. Streaming inference: Processing events continuously as they arrive. Container: Portable package containing application code and runtime dependencies. CI/CD: Continuous integration and continuous delivery or deployment of tested software artefacts. Feature store: System for managing feature definitions, data, lineage, and serving representations. Training–serving skew: Difference between feature computation during training and production inference. Temporal leakage: Use of information unavailable at the prediction time in model development. Data drift: Change in the distribution of model inputs. Concept drift: Change in the relationship between inputs and outcomes. Canary deployment: Gradual release of a new version to a small traffic fraction. SLO: Defined target for a service property such as availability or latency. Rollback: Reversion to a previously approved model, code, or environment. Model lifecycle: Stages from development and validation through production, maintenance, and retirement. Review QuestionsShort Answer Questions- Why is a production ML system more than a trained model?
- Distinguish batch inference from online inference.
- What information should be recorded with a model version?
- What is training–serving skew?
- Why should drift detection not automatically imply retraining?
Long Answer Questions- Explain how data versioning, experiment tracking, and model registries support reproducibility and auditability.
- Compare vertical scaling, horizontal scaling, data parallelism, and model parallelism, including their principal trade-offs.
- Design a CI/CD workflow for promoting a candidate model to production.
- Explain the roles of system, data, model-performance, and fairness monitoring.
- Discuss governance, privacy, security, and human-oversight requirements for high-impact ML applications.
Analytical / Application Questions- A fraud model has stable input distributions but declining recall after a regulatory policy change. Is this data drift, concept drift, or both? Design an investigation and response plan.
- Design a feature and serving architecture for a recommendation system requiring sub-100-millisecond responses and hourly updates. Justify storage, caching, API, monitoring, and rollback choices.
- A retraining job improves aggregate accuracy but reduces recall for a small vulnerable subgroup. Decide whether to deploy it and specify the additional evidence, controls, and stakeholder approvals required.
Multiple Choice Questions with AnswersQuestion 1Which artefact most directly supports tracing a production model to the exact data and code used to train it? A. A mutable deployment tag B. A model record containing data snapshot, code commit, and environment metadata C. A dashboard showing average latency D. A manually edited prediction file Correct Answer: B. A model record containing data snapshot, code commit, and environment metadata Question 2Which inference mode is generally most suitable for generating predictions for an overnight replenishment table? A. Batch inference B. Online inference C. Interactive streaming only D. Manual inference Correct Answer: A. Batch inference Question 3What is the main purpose of a feature store? A. To replace all model registries B. To manage reusable feature definitions and their offline and online representations C. To eliminate the need for data validation D. To guarantee that every model is unbiased Correct Answer: B. To manage reusable feature definitions and their offline and online representations Question 4Which practice best prevents temporal leakage? A. Using the largest possible feature set B. Selecting feature records available no later than the prediction time C. Randomly shuffling all future records into training D. Removing the test set Correct Answer: B. Selecting feature records available no later than the prediction time Question 5A canary deployment primarily means that: A. The old model is permanently deleted before release B. A new version receives a small fraction of traffic before wider promotion C. Predictions are generated without monitoring D. The model is trained only on synthetic data Correct Answer: B. A new version receives a small fraction of traffic before wider promotion Question 6If TP = 80 and FP = 20, what is precision? A. 0.20 B. 0.50 C. 0.80 D. 0.้อม Correct Answer: C. 0.80 Question 7Which statement correctly distinguishes data drift from concept drift? A. Data drift concerns input distributions, whereas concept drift concerns the input–outcome relationship B. Data drift concerns latency, whereas concept drift concerns memory C. They are identical terms in all contexts D. Concept drift can occur only when schemas change Correct Answer: A. Data drift concerns input distributions, whereas concept drift concerns the input–outcome relationship Question 8What does idempotence mean in a production pipeline? A. Every task must run on a GPU B. Repeating a logical operation does not create harmful duplicate effects C. All data must be deleted after training D. A model must have exactly one feature Correct Answer: B. Repeating a logical operation does not create harmful duplicate effects Question 9If request rate λ = 10 requests per second and average service time S = 0.05 seconds, the basic single-server utilization estimate ρ = λ × S is: A. 0.05 B. 0.50 C. 5.00 D. 10.05 Correct Answer: B. 0.50 Question 10Which action is most appropriate when a drift alert is generated? A. Automatically deploy any newly trained model without testing B. Ignore the alert because service availability is unchanged C. Investigate the signal using data quality, outcome, and business evidence D. Delete all historical data Correct Answer: C. Investigate the signal using data quality, outcome, and business evidence
|