What does section 6.1, Defining the task, cover?

This section establishes that defining a machine-learning task begins with understanding the customer's problem and the context in which a model would be used. Explain why good machine-learning work requires understanding the customer's problem, the value of solving it, how a model would be used, what data is available or collectible, and how the business problem maps to a machine-learning task.

What does section 6.1.1, Framing the problem, cover?

This section explains how to frame a machine-learning project by identifying a feasible prediction task, understanding its real-world context, testing its assumptions, and considering its ethical consequences. Describe how to identify the available inputs, the desired targets, and the broad type of machine-learning task, while checking whether suitable training data exists and whether machine learning is the right approach. Explain why problem framing includes investigating current solutions and the constraints of the setting in which a model would operate. Explain why the availability of paired inputs and targets does not establish that the inputs can predict the targets.

What does section 6.1.2, Collecting a dataset, cover?

This section explains how to collect and label training data that supports generalization, with particular attention to representativeness, change over time, and sampling bias. Explain why collecting a good dataset often matters more than incremental modeling improvements, and identify the data properties that affect generalization. Describe why supervised learning requires target annotations and how to choose an annotation approach that produces usable labels. Explain why collected training data should resemble the inputs the deployed model will receive, and what to do when production data cannot be collected directly.

What does section 6.1.3, Understanding your data, cover?

Explore a dataset before training to find predictive patterns and detect problems that could undermine a model in production. Explain why and how to inspect and visualize a dataset before training: the patterns you find can inform feature engineering and reveal potential issues. Describe how to spot missing feature values and uneven class representation, and state that these findings need to be addressed when preparing the data or developing the classifier. Explain target leakage as a feature revealing the target through information that may not be available when the model is used, and describe the production-availability check.

What does section 6.1.4, Choosing a measure of success, cover?

This section explains why a project needs a success metric aligned with its goals and how the type of problem affects the choice of metric. Explain why a machine-learning project should define success before making technical choices, and why its metric should align with the project's higher-level goals. Distinguish the metrics the section suggests for balanced classification from those it suggests for class-imbalanced, ranking, or multilabel problems, and state when a custom metric may be needed.

What does section 6.2, Developing a model, cover?

This section places model development within the broader machine-learning workflow and explains why tutorials can make it seem like the whole job. Explain why model development is only one step in a machine-learning project, even though tutorials and research projects often focus on it alone. Describe the work they commonly assume has already been done or will be handled by someone else.

What does section 6.2.1, Preparing the data, cover?

This section explains how to prepare data for neural networks by vectorizing inputs and targets, normalizing values, and handling missing features. Explain why inputs and targets must be converted into suitable tensors before a neural network can use them, and identify when data is already vectorized. Explain why large or mismatched feature scales can hinder learning, and describe the value ranges and optional per-feature normalization recommended here. Distinguish the suggested treatments for missing categorical and numerical values, and explain what to do when categorical entries may be missing at test time but not in the original training data.

What does section 6.2.2, Choosing an evaluation protocol, cover?

This section explains how to choose a validation protocol that reliably estimates a model’s performance on production data. Explain why validation metrics guide model-development decisions and what the validation protocol is meant to estimate. Distinguish when to use a hold-out validation set, K-fold cross-validation, and iterated K-fold validation. Describe the two cautions for keeping validation results reliable.

What does section 6.2.3, Beating a baseline, cover?

This section explains how to build an initial model that beats a simple baseline, choose a trainable loss, and interpret failure to beat the baseline. Explain that the first modeling goal is a small model that beats a simple baseline, and describe the main choices to focus on: useful features, appropriate architecture, and a workable training configuration. Explain why the measure of success may not be directly usable as a training loss, and describe the section’s example of optimizing crossentropy as a proxy for ROC AUC. Explain what persistent failure to beat a simple baseline can indicate after trying multiple reasonable architectures, and state the two assumptions about inputs and available data that may need reconsideration.

What does section 6.2.4, Scaling up: Developing a model that overfits, cover?

This section explains why to deliberately make a statistically useful model overfit, and how to recognize when it does. Explain why a model with statistical power may still need more capacity, and describe how to make it overfit and recognize that point.

What does section 6.2.5, Regularizing and tuning your model, cover?

This section explains how to improve generalization after a model can overfit, while keeping validation feedback and the final test evaluation reliable. Describe how, after achieving statistical power and the ability to overfit, you repeatedly modify a model, train it, and evaluate it on validation data to improve generalization. Describe the kinds of changes this section suggests trying during tuning, including architecture, regularization, hyperparameters, and optionally data or features. Explain why extensive tuning against validation results can make validation estimates unreliable, and describe how the final model is trained and checked on the test set.

What should I know before reading chapter 6?

The IMDb dataset (chapter 4): The earlier worked examples begin with an available dataset.; Generalization: The goal of machine learning (chapter 5): Generalization is the goal of machine learning.; Things to keep in mind about model evaluation (chapter 5): Model evaluation can be misleading when the data used does not reflect the intended population.; Preparing the data (chapter 4): The text classification example converted word-sequence data into tensors.; Preparing the data (chapter 4): The house-price example normalized features with different ranges.; Training, validation, and test sets (chapter 5): Earlier discussion of training, validation, and test sets.; Beating a common-sense baseline (chapter 5): The idea of comparing a model with a common-sense baseline.; Picking a loss function (chapter 3): The role of a loss function in configuring model training.

Chapter 6: The universal workflow of machine learning

What you will learn in chapter 6 of Deep Learning with Python, Third Edition

The introduction contrasts ready-made training examples with real-world machine learning work, which begins with a problem rather than a dataset.

After this chapter you will be able to

Problem Before Dataset. Explain why a real-world machine learning project cannot usually begin by immediately training a model on a ready-made labeled dataset.
Task context and purpose. Explain why good machine-learning work requires understanding the customer's problem, the value of solving it, how a model would be used, what data is available or collectible, and how the business problem maps to a machine-learning task.
Inputs targets and task type. Describe how to identify the available inputs, the desired targets, and the broad type of machine-learning task, while checking whether suitable training data exists and whether machine learning is the right approach.
Predictive information as hypothesis. Explain why the availability of paired inputs and targets does not establish that the inputs can predict the targets.
Ethical effects of task framing. Explain how a dubious target and biased annotations can turn human prejudice into model outputs that appear objective and operate at scale.
Dataset quality and investment. Explain why collecting a good dataset often matters more than incremental modeling improvements, and identify the data properties that affect generalization.
Supervised annotation choices. Describe why supervised learning requires target annotations and how to choose an annotation approach that produces usable labels.
Training and production representativeness. Explain why collected training data should resemble the inputs the deployed model will receive, and what to do when production data cannot be collected directly.
Exploratory data inspection. Explain why and how to inspect and visualize a dataset before training: the patterns you find can inform feature engineering and reveal potential issues.
Target leakage and production features. Explain target leakage as a feature revealing the target through information that may not be available when the model is used, and describe the production-availability check.
Goal-aligned success metric. Explain why a machine-learning project should define success before making technical choices, and why its metric should align with the project's higher-level goals.
Problem-dependent metric choices. Distinguish the metrics the section suggests for balanced classification from those it suggests for class-imbalanced, ranking, or multilabel problems, and state when a custom metric may be needed.
Model Development in Context. Explain why model development is only one step in a machine-learning project, even though tutorials and research projects often focus on it alone. Describe the work they commonly assume has already been done or will be handled by someone else.
Data vectorization for networks. Explain why inputs and targets must be converted into suitable tensors before a neural network can use them, and identify when data is already vectorized.
Value scales and normalization. Explain why large or mismatched feature scales can hinder learning, and describe the value ranges and optional per-feature normalization recommended here.
Strategies for missing features. Distinguish the suggested treatments for missing categorical and numerical values, and explain what to do when categorical entries may be missing at test time but not in the original training data.
Purpose of validation metrics. Explain why validation metrics guide model-development decisions and what the validation protocol is meant to estimate.
Choice among evaluation protocols. Distinguish when to use a hold-out validation set, K-fold cross-validation, and iterated K-fold validation.
Initial statistical power. Explain that the first modeling goal is a small model that beats a simple baseline, and describe the main choices to focus on: useful features, appropriate architecture, and a workable training configuration.
Trainable loss versus success metric. Explain why the measure of success may not be directly usable as a training loss, and describe the section’s example of optimizing crossentropy as a proxy for ROC AUC.
Meaning of baseline failure. Explain what persistent failure to beat a simple baseline can indicate after trying multiple reasonable architectures, and state the two assumptions about inputs and available data that may need reconsideration.
Deliberate overfitting to find capacity. Explain why a model with statistical power may still need more capacity, and describe how to make it overfit and recognize that point.
Iterative generalization tuning. Describe how, after achieving statistical power and the ability to overfit, you repeatedly modify a model, train it, and evaluate it on validation data to improve generalization.
Validation leakage and final testing. Explain why extensive tuning against validation results can make validation estimates unreliable, and describe how the final model is trained and checked on the test set.
Realistic expectations before launch. Explain why setting expectations is part of a successful launch and how showing surprising model failures can counter unrealistic beliefs about AI.
Business meaning of performance. Describe how to communicate model performance in terms stakeholders can act on, rather than relying on an abstract accuracy figure.
Stakeholder launch threshold tradeoffs. Explain why stakeholders should discuss the probability threshold used at launch and what changes when it is adjusted.
Remote REST API deployment. Describe how REST API serving works and when its connectivity, latency, and data-exposure tradeoffs make it appropriate.
On-device inference tradeoffs. Explain when a model should run on the application's device and what constraints that places on the model.
Browser inference tradeoffs. Describe the benefits and limits of running an inference model directly in a browser or JavaScript desktop application.
Inference model size optimization. Distinguish weight pruning from weight quantization and explain their stated effects on inference models.
Postdeployment monitoring scope. Explain why monitoring continues after deployment and what aspects of a model’s real-world operation should be watched.
Randomized model impact comparison. Describe how randomized A/B testing can help determine whether a deployed model caused a change in outcomes.
Model lifespan and concept drift. Explain why a deployed model will eventually need replacing as changes in production data degrade its performance and relevance.
Preparing the replacement model. Describe how to prepare the next model after launch by watching for data and task changes and continuing to collect and annotate useful examples.

Cover of Deep Learning with Python, Third Edition

liveBook manning.com

Read chapter 6 on liveBook Get the book at manning.com

What it builds on

The IMDb dataset (chapter 4) · The earlier worked examples begin with an available dataset.
Generalization: The goal of machine learning (chapter 5) · Generalization is the goal of machine learning.
Things to keep in mind about model evaluation (chapter 5) · Model evaluation can be misleading when the data used does not reflect the intended population.
Preparing the data (chapter 4) · The text classification example converted word-sequence data into tensors.
Preparing the data (chapter 4) · The house-price example normalized features with different ranges.
Training, validation, and test sets (chapter 5) · Earlier discussion of training, validation, and test sets.
Beating a common-sense baseline (chapter 5) · The idea of comparing a model with a common-sense baseline.
Picking a loss function (chapter 3) · The role of a loss function in configuring model training.

Section by section

Introduction

The introduction contrasts ready-made training examples with real-world machine learning work, which begins with a problem rather than a dataset.

Problem Before Dataset: Explain why a real-world machine learning project cannot usually begin by immediately training a model on a ready-made labeled dataset.
Why it matters: This distinction changes how you approach a new machine learning request before any model training begins.

Key terms: labeled dataset, problem

6.1 Defining the task

This section establishes that defining a machine-learning task begins with understanding the customer's problem and the context in which a model would be used.

Task context and purpose: Explain why good machine-learning work requires understanding the customer's problem, the value of solving it, how a model would be used, what data is available or collectible, and how the business problem maps to a machine-learning task.
Why it matters: Understanding the context helps you define a task that addresses the customer's actual problem.

Key terms: context, business problem, machine learning task

6.1.1 Framing the problem

This section explains how to frame a machine-learning project by identifying a feasible prediction task, understanding its real-world context, testing its assumptions, and considering its ethical consequences.

Inputs targets and task type: Describe how to identify the available inputs, the desired targets, and the broad type of machine-learning task, while checking whether suitable training data exists and whether machine learning is the right approach.
Why it matters: A clear task and realistic data source keep the project from starting with a prediction it cannot train for.
Existing systems and constraints: Explain why problem framing includes investigating current solutions and the constraints of the setting in which a model would operate.
Why it matters: A model is useful only if it fits the process and conditions it is meant to serve.
Predictive information as hypothesis: Explain why the availability of paired inputs and targets does not establish that the inputs can predict the targets.
Why it matters: Recognizing this uncertainty prevents a dataset from being mistaken for proof that the problem is solvable.
Ethical effects of task framing: Explain how a dubious target and biased annotations can turn human prejudice into model outputs that appear objective and operate at scale.
Why it matters: Questioning a project's target and labels can prevent harmful judgments from being automated and amplified.

Key terms: inputs, targets, training data, machine learning task, existing solutions, constraints, full context, hypotheses, inputs X, targets Y

6.1.2 Collecting a dataset

This section explains how to collect and label training data that supports generalization, with particular attention to representativeness, change over time, and sampling bias.

Dataset quality and investment: Explain why collecting a good dataset often matters more than incremental modeling improvements, and identify the data properties that affect generalization.
Why it matters: It helps you decide where to invest effort when model performance needs improvement.
Supervised annotation choices: Describe why supervised learning requires target annotations and how to choose an annotation approach that produces usable labels.
Why it matters: The way targets are obtained directly affects what the model can learn.
Training and production representativeness: Explain why collected training data should resemble the inputs the deployed model will receive, and what to do when production data cannot be collected directly.
Why it matters: Representativeness determines whether a promising test result will hold up in actual use.
Changing production data: Describe concept drift and why it can require continuing data collection, annotation, and retraining.
Why it matters: A dataset that represents users today may not continue to represent them later.
Data collection sampling bias: Explain how a collection method can bias measurements by selecting an unrepresentative group connected to the outcome being predicted.
Why it matters: Even a large collection of measurements can mislead if the collection method selects the wrong people or examples.

Key terms: generalize, data points, labels, features, supervised learning, annotations, targets, crowdsourcing, data annotation software, representative

6.1.3 Understanding your data

Explore a dataset before training to find predictive patterns and detect problems that could undermine a model in production.

Exploratory data inspection: Explain why and how to inspect and visualize a dataset before training: the patterns you find can inform feature engineering and reveal potential issues.
Why it matters: Looking at the data first can guide your features and expose problems before you train a model.
Missing values and class balance: Describe how to spot missing feature values and uneven class representation, and state that these findings need to be addressed when preparing the data or developing the classifier.
Why it matters: Missing values and uneven class counts are easy to overlook unless you check for them explicitly.
Target leakage and production features: Explain target leakage as a feature revealing the target through information that may not be available when the model is used, and describe the production-availability check.
Why it matters: A model that relies on leaked information may not work when it is actually used.

Key terms: explore and visualize, feature engineering, histogram, missing values, class, imbalance, target leaking, targets, production

6.1.4 Choosing a measure of success

This section explains why a project needs a success metric aligned with its goals and how the type of problem affects the choice of metric.

Goal-aligned success metric: Explain why a machine-learning project should define success before making technical choices, and why its metric should align with the project's higher-level goals.
Why it matters: A model can score well on a metric yet fail the project if that metric does not reflect the real goal.
Problem-dependent metric choices: Distinguish the metrics the section suggests for balanced classification from those it suggests for class-imbalanced, ranking, or multilabel problems, and state when a custom metric may be needed.
Why it matters: Matching the metric to the problem makes the reported result a more useful measure of success.

Key terms: metric for success, higher-level goals, balanced classification, accuracy, area under curve (AUC), receiver operating characteristic (ROC), class-imbalanced problems, ranking problems

6.2 Developing a model

This section places model development within the broader machine-learning workflow and explains why tutorials can make it seem like the whole job.

Model Development in Context: Explain why model development is only one step in a machine-learning project, even though tutorials and research projects often focus on it alone. Describe the work they commonly assume has already been done or will be handled by someone else.
Why it matters: It helps you avoid mistaking the model-building portion of a tutorial for the entire project.

Key terms: model development, machine learning workflow, problem definition, dataset collection, model deployment and maintenance

6.2.1 Preparing the data

This section explains how to prepare data for neural networks by vectorizing inputs and targets, normalizing values, and handling missing features.

Data vectorization for networks: Explain why inputs and targets must be converted into suitable tensors before a neural network can use them, and identify when data is already vectorized.
Why it matters: A network needs data in a usable tensor form before it can learn from it.
Value scales and normalization: Explain why large or mismatched feature scales can hinder learning, and describe the value ranges and optional per-feature normalization recommended here.
Why it matters: Comparable feature scales help avoid unstable updates during training.
Strategies for missing features: Distinguish the suggested treatments for missing categorical and numerical values, and explain what to do when categorical entries may be missing at test time but not in the original training data.
Why it matters: The way missing values are represented affects whether the trained model can handle them, especially at test time.

Key terms: data vectorization, tensors, multi-hot encoding, value normalization, homogeneous, mean, standard deviation, gradient updates, missing values, categorical

6.2.2 Choosing an evaluation protocol

This section explains how to choose a validation protocol that reliably estimates a model’s performance on production data.

Purpose of validation metrics: Explain why validation metrics guide model-development decisions and what the validation protocol is meant to estimate.
Why it matters: A useful model depends on validation results that reflect how it will perform in production.
Choice among evaluation protocols: Distinguish when to use a hold-out validation set, K-fold cross-validation, and iterated K-fold validation.
Why it matters: The amount of available data and the precision needed determine which evaluation approach is appropriate.
Validation set reliability safeguards: Describe the two cautions for keeping validation results reliable.
Why it matters: Choosing a protocol is not enough if the validation data cannot provide a trustworthy estimate.

Key terms: generalization, validation metrics, validation protocol, success metric, hold-out validation set, K-fold cross-validation, iterated K-fold validation, representativity, redundant samples, training set

6.2.3 Beating a baseline

This section explains how to build an initial model that beats a simple baseline, choose a trainable loss, and interpret failure to beat the baseline.

Initial statistical power: Explain that the first modeling goal is a small model that beats a simple baseline, and describe the main choices to focus on: useful features, appropriate architecture, and a workable training configuration.
Why it matters: A modest model that clears a baseline shows there is a useful signal to develop further.
Trainable loss versus success metric: Explain why the measure of success may not be directly usable as a training loss, and describe the section’s example of optimizing crossentropy as a proxy for ROC AUC.
Why it matters: The metric used to judge success is not necessarily what the network can optimize during training.
Meaning of baseline failure: Explain what persistent failure to beat a simple baseline can indicate after trying multiple reasonable architectures, and state the two assumptions about inputs and available data that may need reconsideration.
Why it matters: A baseline failure can call the task or data into question, not just the model choice.

Key terms: statistical power, simple baseline, feature engineering, architecture priors, training configuration, loss function, metric, mini-batch, differentiable, backpropagation

6.2.4 Scaling up: Developing a model that overfits

This section explains why to deliberately make a statistically useful model overfit, and how to recognize when it does.

Deliberate overfitting to find capacity: Explain why a model with statistical power may still need more capacity, and describe how to make it overfit and recognize that point.
Why it matters: Seeing where validation performance worsens helps you locate the model-capacity boundary you are trying to approach.

Key terms: statistical power, optimization, generalization, undercapacity, overcapacity, training loss

6.2.5 Regularizing and tuning your model

This section explains how to improve generalization after a model can overfit, while keeping validation feedback and the final test evaluation reliable.

Iterative generalization tuning: Describe how, after achieving statistical power and the ability to overfit, you repeatedly modify a model, train it, and evaluate it on validation data to improve generalization.
Why it matters: It gives you a way to improve the model without spending the final test evaluation during development.
Model improvement options: Describe the kinds of changes this section suggests trying during tuning, including architecture, regularization, hyperparameters, and optionally data or features.
Why it matters: Improving generalization is not limited to changing the number of layers.
Validation leakage and final testing: Explain why extensive tuning against validation results can make validation estimates unreliable, and describe how the final model is trained and checked on the test set.
Why it matters: A strong validation result may be misleading if many decisions were made using that feedback.

Key terms: statistical power, overfit, generalization performance, validation data, test data, architectures, dropout, L1 or L2 regularization, hyperparameters, data curation

6.3 Deploying your model

6.3.1 Explaining your work to stakeholders and setting expectations

This section explains how to set realistic expectations with stakeholders before launching a machine-learning model by showing its failures, translating performance into business consequences, and agreeing on launch tradeoffs.

Realistic expectations before launch: Explain why setting expectations is part of a successful launch and how showing surprising model failures can counter unrealistic beliefs about AI.
Why it matters: People are better prepared to use a model when they have seen where it can fail.
Business meaning of performance: Describe how to communicate model performance in terms stakeholders can act on, rather than relying on an abstract accuracy figure.
Why it matters: Concrete error counts make the costs and benefits of deployment easier to judge.
Stakeholder launch threshold tradeoffs: Explain why stakeholders should discuss the probability threshold used at launch and what changes when it is adjusted.
Why it matters: The right balance between missed cases and false alarms is a business decision, not just a model setting.

Key terms: stakeholders, failure modes, expectations, human-level performance, accuracy, false-negative rates, false-positive rates, business goals, key launch parameters, probability threshold

6.3.2 Shipping an inference model

This section explains how to ship a trained model for inference, choose where it runs, and reduce its resource requirements.

Production inference model requirements: Explain why a production inference model may differ from the Python model used in training and how Keras can export it for use elsewhere.
Why it matters: Shipping a model means preparing it for the environment and workload in which it will actually run.
Remote REST API deployment: Describe how REST API serving works and when its connectivity, latency, and data-exposure tradeoffs make it appropriate.
Why it matters: Remote serving is convenient only if the application can tolerate its network and server-side data requirements.
On-device inference tradeoffs: Explain when a model should run on the application's device and what constraints that places on the model.
Why it matters: Running locally can solve network and privacy problems, but the target hardware limits what model can be shipped.
Browser inference tradeoffs: Describe the benefits and limits of running an inference model directly in a browser or JavaScript desktop application.
Why it matters: Browser inference changes both who pays for computation and who can access the model.
Inference model size optimization: Distinguish weight pruning from weight quantization and explain their stated effects on inference models.
Why it matters: These techniques help make inference feasible where memory, power, or latency is constrained.

Key terms: inference, export(), TensorFlow Serving, ONNX, computation graph, REST API, managed third-party cloud service, on-device, TensorFlow Lite, ONNX runtime

6.3.3 Monitoring your model in the wild

Deploying a model is not the end of the workflow: its production behavior and impact must be monitored using comparisons and ongoing evaluation.

Postdeployment monitoring scope: Explain why monitoring continues after deployment and what aspects of a model’s real-world operation should be watched.
Why it matters: A model can work as expected before launch yet have different results in production.
Randomized model impact comparison: Describe how randomized A/B testing can help determine whether a deployed model caused a change in outcomes.
Why it matters: A comparison with the old process helps distinguish the model’s effect from unrelated changes.
Production prediction audits: Describe how to check predictions against production data and what alternative the section suggests when manual audits are impossible.
Why it matters: Audits provide a way to check predictions on the data the model actually encounters.

Key terms: monitoring, production data, business metrics, randomized A/B testing, control subset, old process, manual audit, manually annotated, user surveys

6.3.4 Maintaining your model

This section explains why deployed models need replacement and how to prepare for the next version.

Model lifespan and concept drift: Explain why a deployed model will eventually need replacing as changes in production data degrade its performance and relevance.
Why it matters: A model that works at launch may not keep working as the data it encounters changes.
Preparing the replacement model: Describe how to prepare the next model after launch by watching for data and task changes and continuing to collect and annotate useful examples.
Why it matters: Collecting relevant examples while the current model runs gives its replacement better training data.

Key terms: concept drift, production data, next generation, label set, annotation pipeline

6.4 Summary

Where this is used later

The universal machine learning workflow (chapter 20) · The earlier treatment of defining the task.
Downloading the data (chapter 8) · Choosing a measure of success for a machine-learning task.
Monitoring and visualization with TensorBoard (chapter 7) · The process of developing and improving a model.
Data preprocessing (chapter 8) · Image data preprocessing applies the need to provide network-ready data.
Preparing text data (chapter 14) · Preparing text data applies the need to represent text in a form a model can use.
Preparing the data (chapter 13) · The general need to prepare data before model training.
Stacking recurrent layers (chapter 13) · The workflow of increasing model capacity until overfitting becomes the main obstacle.
Faster inference with quantization (chapter 18) · Revisits quantization as a way to make inference faster.

Concepts explained in this chapter

generalizationThe ability of a model or agent to perform well on novel situations different from those seen during training or prior exposure.
concept driftA change over time in the statistical properties of production data that can degrade a deployed model's performance.
production dataReal operational data encountered after deployment, used here as the reference for estimating future performance.
data annotationThe process of having people manually label or correct dataset examples.
ONNXAn open format and runtime ecosystem for representing and executing trained machine-learning models outside the original training framework.
RESTREST is an architectural style for distributed hypermedia systems that organizes interactions around resources and representations through constraints including a uniform interface, stateless communication, cacheability, and layered components.
TFLiteA framework for efficient on-device TensorFlow inference on mobile and embedded hardware.
TensorFlow ServingA serving library for deploying TensorFlow computation graphs with saved weights as inference services.
TensorFlow.jsA JavaScript TensorFlow ecosystem library for running models in browsers or other JavaScript environments.
language modelA language model trained on large text corpora that can generate human-sounding responses, mentioned here as an example of a system that may be modular but still lacks recombination ability.
productionA production environment is the live operational setting in which software or other systems serve real users, workloads, or business processes.
pruningA model-compression technique that removes less important weights or connections to reduce model size and cost.
quantizationThe technique of reducing numeric precision of model weights or activations to speed up computation while preserving output behavior as much as possible.
labelThe desired output values that a model is trained to match for each input example.
calibration dataData whose distribution matches the real-world inputs a model will encounter after deployment.
data collectionThe process of gathering data examples for a machine learning project before model development.
selection biasA bias introduced when the data collection process produces a sample that is not representative of the target population.
machine learning problemA task framed so that a model can be trained on data to make useful predictions or decisions.
baselineA simple reference method or model used to judge whether a machine-learning system outperforms a naive or trivial alternative.
machine learning workflowThe end-to-end sequence of steps for defining, building, evaluating, deploying, and maintaining a machine learning system.
missing valueAn absent data field in a sample that must be handled explicitly during preprocessing.
normalizationThe process of rescaling or normalizing features so they have more stable numerical properties for learning.
preprocessingThe transformation of raw data into a form suitable for input to a model.
vectorizationThe process of converting data into vector form so it can be used by machine-learning code.
iterated K-fold validation with shufflingA repeated cross-validation protocol that cycles through multiple train/validation splits to obtain a more reliable estimate.
overfittingThe failure mode where performance improves on training data while degrading on unseen data because the model has adapted too specifically to the training set.
architecture priorsAn inductive bias about which model structures are likely to work well for a task before training on data.
feature engineeringThe manual design or transformation of input variables into representations better suited for a learning algorithm.
dropoutA neural-network regularization technique that randomly zeroes activation entries during training and behaves differently at inference time.
hyperparameterA user-chosen model or training setting, such as layer count or activation choice, that is set before training and tuned externally rather than learned by backpropagation.
validation_data argumentA fit() argument that supplies a separate dataset for computing validation loss and metrics during training.
objective functionA function that compares predictions with targets and returns a scalar indicating how wrong the model is for a given task.
evaluation datasetA held-out subset of the training data used during training to monitor performance and tune choices without touching the final test set.
cross-validationA validation procedure that partitions data into K folds, trains on K−1 folds, and evaluates on the remaining fold in rotation.
classifierA supervised learning task that assigns text inputs to one of several classes.
image segmentationA vision task that assigns a label to each pixel or region of an image, providing denser localization than object detection.
linear regressionA transformation that preserves linear structure and can be represented by matrix multiplication.
multilabel classificationA classification task in which each example may belong to multiple classes at the same time, even though there are multiple possible classes overall.
multi-hot encodingA representation scheme where multiple positions are set to 1 and all others to 0 to indicate the presence or absence of several categories or symbols.
regularizationA method that constrains a model during training to reduce overfitting and improve generalization.

These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.