ML Systems, MLOps and Enterprise Deployment

Introduction

A machine-learning model is useful to an organization only when it can be operated reliably in a changing environment. A high validation score is therefore an incomplete definition of success. Production ML requires coordinated management of data, code, features, models, infrastructure, interfaces, security, people, and operational processes. This discipline is commonly called MLOps: the engineering and governance practices used to develop, deploy, monitor, and improve machine-learning systems.

ML systems differ from conventional software systems because their behavior depends not only on program logic but also on data distributions, labeling processes, feature transformations, model parameters, and feedback loops. A production incident can arise from a software defect, a corrupted data source, a changed customer population, a failed feature pipeline, an expired certificate, or a model that has become statistically obsolete. Consequently, reliable ML engineering must integrate software engineering, data engineering, statistics, distributed systems, security, and organizational governance.

This chapter examines production pipelines for versioning, feature management, distributed training, serving, monitoring, drift detection, retraining, incident response, and enterprise decision-making. It also evaluates cloud, edge, AutoML, and build-versus-buy alternatives.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain the architecture and lifecycle of an enterprise ML system.

2. Design reproducible versioning and feature-management processes.

3. Compare training and serving architectures, including distributed and edge deployment.

4. Select meaningful operational, statistical, and business monitoring metrics.

5. Design drift detection, retraining, rollback, and incident-response procedures.

6. Evaluate cloud, AutoML, and build-versus-buy choices using technical and managerial criteria.

7. Identify governance, privacy, security, fairness, and regulatory risks in deployed ML.

1. The Production ML Lifecycle

A production ML lifecycle is a controlled sequence rather than a one-time model-building exercise. A typical lifecycle contains:

• problem definition and acceptance criteria;
• data acquisition, validation, and labeling;
• feature engineering;
• training and evaluation;
• model registration and approval;
• packaging and deployment;
• online or batch inference;
• monitoring and feedback collection;
• retraining, rollback, retirement, and audit.

The lifecycle should be represented as a dependency graph. A model artifact is not sufficient for reproducibility unless its associated training data, label definition, feature code, hyperparameters, software environment, random seeds where relevant, and evaluation results are known. A useful production identity is therefore a tuple such as:

model release = (code version, data version, feature version, environment version, parameter configuration).

This notation is conceptual rather than a universal standard; each component must be stored in an auditable registry. Reproducibility means that an authorized engineer can reconstruct the artifact or explain any unavoidable nondeterminism.

1.1 System layers

An enterprise ML platform commonly contains the following layers:

1. Data layer: operational databases, event streams, files, warehouses, and external sources.

2. Data-quality layer: schema checks, freshness checks, range checks, uniqueness checks, and label validation.

3. Feature layer: transformations, offline feature tables, online feature stores, and feature definitions.

4. Training layer: orchestration, distributed computation, experiment tracking, validation, and model registration.

5. Serving layer: batch jobs, real-time APIs, streaming inference, or embedded models.

6. Observability layer: logs, metrics, traces, data-quality measurements, drift statistics, and business outcomes.

7. Governance layer: identity and access management, lineage, approval, risk classification, privacy, documentation, and audit.

The architecture should separate control plane responsibilities—configuration, metadata, authorization, and deployment—from data plane responsibilities—training data processing and inference traffic. This separation improves security and reduces the likelihood that an operational failure changes model behavior silently.

2. Versioning, Reproducibility and Lineage

Traditional source-code version control is necessary but insufficient. ML teams should version at least four categories of artifacts:

• Code: application code, feature transformations, training scripts, infrastructure definitions, and tests.
• Data: immutable snapshots, partition identifiers, labeling versions, and data contracts.
• Models: weights, architecture, preprocessing pipeline, calibration information, and signatures.
• Configuration and environment: hyperparameters, container image digests, library versions, hardware type, and deployment settings.

A data version need not mean physically copying every byte. It may be an immutable object-store snapshot, a table time-travel point, or a content-addressed manifest. The important properties are immutability, discoverability, access control, and lineage.

2.1 Data and model lineage

Lineage records the origin and transformations of an artifact. For a prediction, useful lineage may include the model release, input feature values or their source references, feature transformation version, request timestamp, and decision policy. Lineage supports debugging, reproducibility, regulatory inquiry, and deletion requests. It also exposes hidden coupling—for example, a model that depends on a feature generated by a manually maintained spreadsheet.

2.2 Testing strategy

Production ML requires several test classes:

• Unit tests: verify individual transformations and utility functions.
• Schema and contract tests: verify column names, types, permitted values, freshness, and producer-consumer agreements.
• Data-quality tests: detect missingness, duplicates, outliers, and impossible relationships.
• Training tests: confirm that training completes, metrics fall within reasonable bounds, and no target leakage occurs.
• Model tests: verify input and output schemas, latency, resource use, calibration, fairness indicators, and robustness to selected perturbations.
• Integration tests: exercise feature pipelines, registries, serving systems, and monitoring.
• Shadow or canary tests: compare a new model with the incumbent under controlled traffic.

A model should not be promoted merely because its aggregate accuracy is higher. Promotion criteria should include minimum subgroup performance, data-quality status, latency budgets, security review, and business acceptance criteria.

3. Feature Management

A feature is an input variable derived from raw data for use by a model. Feature engineering can be implemented in training pipelines, batch feature stores, online feature stores, or shared transformation libraries. The central production risk is training-serving skew: the model sees one definition during training and another at inference time.

3.1 Offline and online feature stores

An offline store supports historical training and analysis. It is generally optimized for large scans and reproducible point-in-time queries. An online store supports low-latency retrieval of recent feature values. A mature feature-management design defines each feature once, specifies its data type and ownership, records freshness and validity expectations, and makes both historical and online computation consistent.

Point-in-time correctness is essential. When constructing a training example at time t, a feature must use only information available at or before t. Using a later transaction outcome or a future customer status creates target leakage and produces an unrealistically high evaluation score.

3.2 Feature contracts

A feature contract should specify:

• semantic meaning and unit;
• owner and source system;
• type, permitted range, and missing-value policy;
• freshness service-level objective;
• transformation logic and version;
• privacy classification;
• offline and online availability;
• expected distribution and monitoring thresholds.

Feature reuse lowers development cost, but it also creates shared-failure risk. A defective common feature can affect many models. Ownership, impact analysis, and dependency-aware deployment are therefore necessary.

4. Distributed Training and Pipeline Orchestration

Large datasets and models may exceed the memory or computation capacity of one machine. Distributed training divides work among workers. In data parallelism, each worker holds a copy of the model and processes a different mini-batch; gradients are aggregated before parameters are updated. In model parallelism, different parts of a model are placed on different devices. Pipeline parallelism divides sequential model stages and overlaps their execution.

For synchronous data-parallel training, an idealized communication step can be represented as:

T_step ≈ T_compute + T_communication,

where T_compute is local computation time and T_communication is the time required to exchange gradients or parameter updates. The approximation omits scheduling, input, synchronization, and fault-recovery overhead. Scaling is beneficial only when the reduction in computation time exceeds the added communication and coordination costs.

If one worker processes b examples per step and there are w workers, the nominal global batch size is:

B = b w,

assuming every worker contributes one batch and no gradient accumulation is used. If gradients are accumulated for a steps before an update, the effective batch size becomes B = b w a. Changes in batch size can alter optimization behavior; learning-rate adjustments are not universally valid and must be experimentally evaluated.

4.1 Reliability in distributed training

Distributed jobs require checkpointing, retry policies, worker health detection, idempotent data reads, and deterministic or documented restart behavior. Checkpoints should contain model parameters, optimizer state, training progress, and relevant random-state information where reproducibility is required. Object storage is often used because it survives worker failure.

Pipeline orchestration should make stages observable and restartable. A successful data-extraction stage should not be rerun unnecessarily when only model evaluation failed. However, cached outputs must be invalidated when an upstream version changes. Directed acyclic graphs, artifact hashes, and explicit dependency specifications help avoid both redundant computation and stale results.

5. Model Serving Architectures

5.1 Batch serving

Batch inference produces predictions for a defined population at scheduled intervals. It is appropriate for billing risk scores, recommendation candidates prepared overnight, inventory forecasts, and periodic prioritization. Batch serving is usually less sensitive to per-request latency but requires attention to data completeness, duplicate processing, late-arriving data, and output delivery.

5.2 Online serving

Online serving exposes a model through an API or service. Important design dimensions include latency percentile targets, throughput, availability, concurrency, input validation, authentication, rate limiting, and graceful degradation. Average latency is inadequate for many applications; the 95th or 99th percentile may determine user experience and capacity requirements.

A serving interface should include a versioned input schema and an explicit output contract. It should reject malformed or unauthorized requests rather than silently coercing them. Timeouts and circuit breakers prevent a slow dependency from exhausting service resources.

5.3 Streaming and asynchronous serving

Streaming inference processes events continuously, often with stateful windows. It is useful for fraud detection and industrial monitoring but introduces event-time versus processing-time issues, out-of-order events, replay semantics, and state recovery. Asynchronous serving decouples request submission from result retrieval and can improve throughput for expensive predictions.

5.4 Deployment patterns

• Blue-green deployment: maintain two environments and switch traffic between them. Rollback is straightforward but requires duplicate capacity.
• Canary deployment: expose a small, controlled fraction of traffic to the new release and expand only if evidence is satisfactory.
• Shadow deployment: run the new model without using its predictions for decisions; compare behavior and resource use.
• A/B testing: randomly assign eligible traffic to alternatives and evaluate predefined outcomes. Statistical design must account for interference, novelty effects, and ethical constraints.

A model registry should distinguish stages such as development, validation, approved, production, and retired. Stage transitions require documented evidence and authorized ownership.

6. Monitoring and Observability

Monitoring must cover four perspectives:

1. Infrastructure: CPU, memory, accelerator utilization, disk, network, saturation, and error rates.

2. Service: throughput, availability, timeout rate, and latency percentiles.

3. Data and model: missingness, schema changes, feature distributions, prediction distributions, calibration, and performance.

4. Business and safety: revenue, approval quality, fraud loss, customer complaints, adverse outcomes, and fairness indicators.

The distinction between monitoring and observability is useful. Monitoring answers whether known conditions are within limits. Observability supports investigation of unknown failure modes through correlated logs, metrics, traces, lineage, and representative samples.

6.1 Drift

Drift is a change relevant to a deployed model. Common categories include:

• Data or covariate drift: the distribution of inputs changes, P(X).
• Prediction drift: the distribution of outputs changes, P(Ŷ).
• Concept drift: the relationship between inputs and target changes, P(Y|X).
• Label or prior drift: the prevalence of outcomes changes, often represented by P(Y).

Drift is not automatically degradation. A seasonal change may be expected, while a change in customer behavior may be beneficial or harmful. Detection should therefore be linked to business context and, where possible, delayed ground-truth performance.

For a binary classifier, a confusion matrix can be used to define precision and recall:

precision = TP/(TP+FP),

recall = TP/(TP+FN),

where TP, FP, and FN denote true positives, false positives, and false negatives. These measures assume a defined positive class and labeled observations. Precision is sensitive to prevalence, while recall measures the fraction of actual positives detected. Neither alone describes all operational costs.

A common distribution comparison is the population stability index (PSI), calculated for corresponding bins as:

PSI = Σ_i (p_i - q_i) ln(p_i/q_i),

where p_i is a reference proportion and q_i is the current proportion in bin i; both must be positive. Binning choices affect the value, and PSI is a screening statistic rather than proof of model failure. Zero proportions require a documented smoothing convention. Alternative methods include divergence measures, two-sample tests, quantile comparisons, and domain-specific detectors.

Monitoring thresholds should be designed with alert severity, evaluation window, sample size, seasonality, and multiple-testing effects in mind. Excessive alerts cause fatigue; silent failure is worse than a small number of well-prioritized alerts.

7. Retraining and Incident Response

Retraining can be scheduled, event-triggered, or human-approved. Scheduled retraining is predictable but may waste resources or miss sudden change. Event-triggered retraining reacts to drift or performance decline but can create unstable model churn. A robust policy separates detection from promotion: an alert may initiate data collection and candidate training, but deployment still requires validation and approval.

A retraining policy should define:

• trigger conditions and minimum sample sizes;
• training window and label maturity requirements;
• evaluation datasets, including temporal and subgroup splits;
• promotion gates and rollback criteria;
• maximum model age and retirement rules;
• human approval responsibilities;
• audit and notification requirements.

7.1 Incident response

An ML incident is a failure or unacceptable risk affecting model behavior, service reliability, compliance, or stakeholders. The response process includes detection, triage, containment, diagnosis, recovery, communication, and learning.

Containment options include disabling a feature, routing traffic to the previous model, using a conservative rules-based fallback, reducing automation, or temporarily suspending decisions. The safest fallback depends on the domain. In medical or financial contexts, an apparently simple fallback can itself create harm.

A post-incident review should be blameless but not responsibility-free. It should identify the technical and organizational causes, quantify impact, document decisions, improve tests and runbooks, and assign owners with deadlines. Emergency changes should be logged and subsequently reconciled with the normal approval process.

8. Cloud, Edge, and Hybrid Deployment

Cloud platforms provide elastic compute, managed storage, distributed training services, registries, orchestration, and monitoring. They can reduce infrastructure-management burden and accelerate experimentation. Their disadvantages include variable cost, vendor dependence, data-transfer charges, regional availability constraints, and governance complexity.

Edge deployment places inference near the data source, such as a vehicle, factory device, mobile phone, or retail terminal. Benefits include lower latency, reduced bandwidth use, resilience to intermittent connectivity, and improved local privacy. Constraints include limited compute and memory, hardware diversity, physical tampering, difficult fleet management, and delayed model feedback.

Model compression methods—quantization, pruning, knowledge distillation, and architecture selection—can reduce edge resource requirements. Compression may affect accuracy, calibration, robustness, and fairness; it must be evaluated on the deployment hardware rather than assumed to be harmless.

Hybrid architectures often train in a central environment while serving at the edge. They require secure model distribution, device identity, signed artifacts, version compatibility, telemetry aggregation, remote rollback, and protection against extraction or tampering. Federated learning can reduce centralization of raw data, but it does not automatically guarantee privacy or eliminate poisoning, inference, communication, and heterogeneity challenges.

9. AutoML and Build-versus-Buy Decisions

AutoML can automate portions of feature selection, architecture search, hyperparameter optimization, and pipeline construction. It is valuable when teams need strong baselines quickly or lack specialized expertise. However, AutoML does not remove the need to define the target correctly, prevent leakage, validate temporal behavior, monitor deployment, assess fairness, or govern decisions. Search over many configurations also increases the risk of overfitting to a validation set.

A build-versus-buy decision should assess:

• strategic differentiation and intellectual property;
• data sensitivity and regulatory constraints;
• required latency, availability, and geographic coverage;
• integration with existing identity, data, and monitoring systems;
• total cost of ownership, not only license price;
• vendor lock-in and exit portability;
• customization, explainability, and auditability;
• vendor security, service-level commitments, and incident history;
• internal skills and long-term maintenance capacity.

A purchased model or platform still requires organizational ownership. Contracts should specify data use, retention, breach notification, model changes, service levels, audit rights, and exit procedures. A hybrid strategy is common: buy commodity platform capabilities while building domain-specific data products, evaluation, policy logic, and governance.

10. Governance, Security and Responsible Deployment

ML governance translates organizational obligations into controls. A risk-tiered approach is preferable to applying identical controls to every model. A low-risk demand forecast and a high-impact lending model should not face the same approval burden, although both require basic security and quality controls.

Important governance practices include model cards or equivalent documentation, data sheets, risk assessments, documented intended use and limitations, approval records, lineage, access controls, retention schedules, and periodic review. High-impact applications require particular attention to explainability, contestability, human oversight, disparate impact, and lawful basis for data processing.

Security threats include data poisoning, adversarial inputs, model extraction, membership inference, prompt or input manipulation in ML-enabled applications, compromised dependencies, and unauthorized access to training data or model artifacts. Controls include least-privilege access, encryption, network isolation, secret management, signed containers and models, dependency scanning, vulnerability management, input validation, abuse monitoring, and red-team testing.

Privacy-preserving methods such as minimization, pseudonymization, access restriction, differential privacy, and federated approaches may reduce risk, but their protection properties differ. Privacy is not achieved merely by removing names; quasi-identifiers and model outputs can still expose individuals.

Fairness evaluation requires a defined population, protected or relevant groups, decision context, and choice of metric. Metrics can conflict, particularly when base rates differ. Therefore fairness cannot be solved by selecting a single universal threshold; it requires domain-specific judgment, legal analysis, stakeholder participation, and ongoing monitoring.

11. Illustrative Case: Real-Time Industrial Quality Inspection

Background

A manufacturer uses cameras and sensor data to identify defective products on a high-speed assembly line. The initial prototype is a convolutional model evaluated on a randomly split image dataset.

Problem

After deployment, the defect-detection rate falls on one production line. The model service remains available and latency is within target, so infrastructure dashboards show no incident. Operators report that performance is poor after a camera replacement and during a change in material supplier.

Analysis

The team examines lineage and finds that the training images came from the old camera, while the new camera has different color response and resolution. Feature and image-quality monitoring also reveals a distribution shift. Delayed quality-control labels show that recall declined, although aggregate accuracy initially appeared stable because defects are rare. The original random split had allowed near-duplicate images from the same production batch in both training and validation, overstating generalization.

Approach and solution

The organization introduces camera metadata and image-quality checks, creates time- and line-based evaluation splits, and stores immutable data manifests. It deploys a shadow model trained on recent, reviewed samples. A canary release is allowed only if recall meets a minimum threshold on each critical line and the false-reject rate remains within the operational limit. Until validation is complete, the previous model and manual inspection are used as a controlled fallback. A retraining trigger combines sustained feature drift, a minimum number of mature labels, and evidence of performance decline. Model and camera firmware releases are linked in the registry.

Outcome

The revised process detects camera changes before silent degradation, improves temporal generalization, and makes rollback possible. The new model is not promoted solely on overall accuracy; line-level recall, false rejects, latency, and operator workload are evaluated together.

Learning points

The case demonstrates that model quality is contextual, delayed labels are operationally important, random validation can be misleading, and data, hardware, model, and deployment versions must be managed as one system.

12. Best-Practice Design Principles

1. Define measurable business, technical, safety, and fairness acceptance criteria before training.

2. Treat data, features, code, environments, and models as versioned production artifacts.

3. Enforce point-in-time correctness and test explicitly for leakage.

4. Use automated quality gates and human approval for high-impact releases.

5. Prefer reproducible pipelines with immutable artifacts and clear ownership.

6. Monitor service health, data behavior, model performance, and business outcomes together.

7. Separate drift detection from automatic deployment of a retrained model.

8. Use canary, shadow, and rollback mechanisms appropriate to risk.

9. Design fallback behavior before an incident occurs.

10. Evaluate total cost, portability, governance, and exit risk in platform decisions.

11. Test compressed and edge models on actual target hardware.

12. Conduct post-incident learning and periodically retire unused models and features.

Challenges and Limitations

MLOps does not eliminate uncertainty. Labels may be delayed, biased, incomplete, or affected by the model’s own decisions. Drift detectors can generate false alarms, while stable input distributions can conceal concept drift. Reproducibility may be limited by nondeterministic hardware kernels or unavailable historical data. Distributed infrastructure adds cost and operational complexity. Monitoring can become surveillance if data collection is excessive. Automated retraining may amplify labeling errors or feedback loops. Finally, governance frameworks cannot resolve every normative disagreement; some decisions require institutional and democratic judgment rather than technical optimization.

Contemporary Developments

Current enterprise practice is moving toward platform engineering, policy-as-code, model supply-chain security, evaluation-driven release processes, and unified observability for traditional and generative models. Feature and model registries increasingly connect to software supply-chain tools and data catalogs. Large models raise additional concerns about prompt and retrieval lineage, evaluation under changing context, inference cost, content safety, and confidential-data leakage. The underlying principles remain stable: explicit contracts, versioned artifacts, measurable risk, controlled change, and accountable ownership.

Chapter Summary

Production ML is a lifecycle and systems-engineering discipline. Reliable deployment requires versioning of code, data, features, models, configurations, and environments; lineage makes those artifacts auditable and reproducible. Feature stores and point-in-time correctness reduce training-serving skew and leakage. Distributed training improves capacity but introduces communication, checkpointing, and failure-management requirements. Batch, online, streaming, edge, and hybrid serving architectures address different latency, connectivity, and governance constraints.

Effective observability combines infrastructure, service, data, model, business, and safety signals. Covariate, prediction, and concept drift must be interpreted in context rather than treated as automatic evidence of failure. Retraining should use explicit triggers, mature labels, validation gates, and rollback procedures. Incident response requires containment, diagnosis, communication, recovery, and post-incident learning.

Cloud and AutoML can accelerate delivery but introduce cost, dependency, and governance considerations. Build-versus-buy analysis must include total ownership cost, portability, security, data sensitivity, and strategic differentiation. Responsible enterprise deployment requires privacy, security, fairness, documentation, human oversight, and risk-proportionate controls. The central professional principle is that a model is only one component of a continuously changing sociotechnical system.

Key Terms

MLOps: Practices for developing, deploying, operating, and governing machine-learning systems.

Model registry: A controlled repository for model artifacts, metadata, versions, and lifecycle stages.

Data lineage: A record of data origin, transformations, dependencies, and uses.

Feature store: A system that manages reusable feature definitions and their historical or online values.

Training-serving skew: A mismatch between feature computation during training and inference.

Point-in-time correctness: Use of only information available at the prediction time when constructing training examples.

Data parallelism: Distributed training in which workers process different data batches using replicated model parameters.

Model parallelism: Distribution of different model components across computational devices.

Batch inference: Prediction generation for a collection of records on a scheduled or asynchronous basis.

Online inference: Low-latency prediction for individual or small groups of requests.

Canary deployment: Gradual release of a new version to a controlled fraction of traffic.

Shadow deployment: Running a candidate model without using its predictions for live decisions.

Observability: The ability to understand system behavior through connected logs, metrics, traces, and artifacts.

Covariate drift: Change in the distribution of model inputs.

Concept drift: Change in the relationship between inputs and the target.

PSI: A binned statistic used to screen for differences between reference and current distributions.

Model rollback: Restoration of a previous approved model release.

AutoML: Automated search or construction of parts of an ML pipeline.

Model card: Documentation describing a model’s intended use, evaluation, limitations, and risks.

Training-serving skew: A mismatch between the transformations or feature values used in training and production serving.

Review Questions

Short Answer Questions

1. Why is source-code versioning alone insufficient for reproducible ML?

2. Distinguish batch inference from online inference.

3. What is point-in-time correctness, and why does it matter?

4. Name four categories of production monitoring.

5. Why should drift detection not automatically trigger model promotion?

Long Answer Questions

1. Explain an end-to-end enterprise ML lifecycle and identify control points at each stage.

2. Compare blue-green, canary, shadow, and A/B deployment strategies, including their risks and suitable uses.

3. Discuss the architecture and operational challenges of distributed training.

4. Evaluate cloud, edge, and hybrid deployment for a latency-sensitive industrial application.

5. Develop a governance framework for a high-impact ML system, including privacy, security, fairness, documentation, and human oversight.

Analytical / Application Questions

1. A fraud model’s input distribution changes substantially, but its labeled precision remains stable. Analyze possible explanations and recommend an operational response.

2. Design a retraining and rollback policy for a medical triage model with delayed labels and high consequences for false negatives.

3. An organization can buy a managed ML platform or build an internal platform. Construct a decision matrix using cost, skills, data sensitivity, portability, reliability, and strategic differentiation, and justify the decision.

Multiple Choice Questions with Answers

Question 1

Which artifact combination is most necessary for reproducing a production model release?

A. Only the model weights and accuracy score

B. Code, data, feature definitions, environment, and configuration

C. Only the source code and serving URL

D. The dashboard screenshots and user documentation

Correct Answer: B. Code, data, feature definitions, environment, and configuration

Question 2

What is the primary purpose of point-in-time correctness?

A. To reduce model serving latency

B. To ensure training features do not use future information

C. To increase the number of model parameters

D. To eliminate the need for labels

Correct Answer: B. To ensure training features do not use future information

Question 3

In synchronous data parallelism, increasing the number of workers can reduce scaling efficiency mainly because of increased

A. label availability

B. model interpretability

C. communication and synchronization overhead

D. database normalization

Correct Answer: C. communication and synchronization overhead

Question 4

Which deployment pattern runs a candidate model while its predictions do not affect live decisions?

A. Blue-green deployment

B. Shadow deployment

C. Canary deployment

D. Hard cutover

Correct Answer: B. Shadow deployment

Question 5

Concept drift refers to a change in

A. the relationship between inputs and the target

B. the size of the model file only

C. the API authentication method

D. the hardware clock frequency

Correct Answer: A. the relationship between inputs and the target

Question 6

For a binary classifier, recall is calculated as

A. TP/(TP+FP)

B. TN/(TN+FN)

C. TP/(TP+FN)

D. FP/(FP+TN)

Correct Answer: C. TP/(TP+FN)

Question 7

Which feature-store property most directly prevents future information from entering a historical training example?

A. Point-in-time historical retrieval

B. Higher online request throughput

C. Larger model size

D. More frequent dashboard refreshes

Correct Answer: A. Point-in-time historical retrieval

Question 8

Which is a principal advantage of edge inference?

A. It always provides unlimited compute

B. It removes the need for model monitoring

C. It can reduce latency and dependence on connectivity

D. It guarantees fairness across groups

Correct Answer: C. It can reduce latency and dependence on connectivity

Question 9

Why should a build-versus-buy decision include exit portability?

A. To ensure the model has more parameters

B. To assess the consequences of vendor dependence

C. To avoid collecting evaluation data

D. To replace security testing

Correct Answer: B. To assess the consequences of vendor dependence

Question 10

Which response is generally appropriate when a production model is causing unacceptable harm?

A. Ignore the issue if infrastructure metrics are normal

B. Increase traffic to obtain more evidence without controls

C. Contain the incident using rollback or an approved fallback

D. Delete all monitoring records

Correct Answer: C. Contain the incident using rollback or an approved fallback