Task 2.2 - Train, fine-tune, and customize models for ML and AI solutions
Overview
Task 2.2, Train, fine-tune, and customize models for ML and AI solutions, is where the approach chosen in Task 2.1 becomes a job that runs.
For a trained model that means an algorithm or a script, a set of hyperparameters, and a search across them. For a foundation model it means prompt engineering, a customization job, or improvements to the retrieval the application depends on.
As you review these lessons for Task 2.2, check that you understand how to do the following.
- Apply Amazon SageMaker AI built-in algorithms and common ML libraries.
- Configure SageMaker AI script mode with supported frameworks for simplicity and performance.
- Implement hyperparameter optimization (for example, SageMaker AI automatic model tuning [AMT]).
- Implement training time reduction techniques (for example, early stopping, distributed training).
- Prevent model overfitting, underfitting, and catastrophic forgetting.
- Combine multiple ML models to improve performance or reduce cost.
- Adjust fundamental hyperparameters (for example, epoch, steps, batch size).
- Apply customization techniques for AI solutions (for example, task-specific prompt engineering, fine-tuning).
- Optimize retrieval components and embedding models.
AWS services overview
The services here divide by what supplies the training logic and what supplies the scale. A managed training service runs a built-in algorithm or a script you wrote, a tuning capability searches hyperparameter ranges for you, and the generative AI path customizes a model instead of fitting one from scratch. Review each service to learn more.
| AWS Service | Description |
|---|---|
| Amazon SageMaker AI | Runs the training job three ways: a built-in algorithm, a training script of your own on a container AWS maintains for the framework, or a container you build. |
| Amazon SageMaker AI automatic model tuning (AMT) | Searches the hyperparameter ranges you specify by running many training jobs, and keeps the combination that scores best on the objective metric you choose. |
| Amazon SageMaker AI distributed training libraries | Split the data or the model itself across the instances in a cluster, for a job that will not finish in reasonable time or will not fit in one device's memory. |
| Amazon SageMaker JumpStart | Fine-tunes a pre-trained model from a curated hub, so a customization run does not begin with an empty training loop. |
| Amazon Bedrock | Customizes a foundation model through supervised fine-tuning, reinforcement fine-tuning, or distillation into a smaller and faster student model. |
| Amazon Bedrock Knowledge Bases | Holds the retrieval components a generative AI application leans on, including the embedding model and the vector store the retriever queries. |
| Amazon CloudWatch | Collects the metrics and logs a training job emits, which is where a loss curve that stopped improving becomes visible. |
Knowledge Check
A training script written in a supported deep learning framework has to run as a managed training job, and the team prefers not to build and maintain a container image. Which option fits? (Choose 1)
- A. Supply the script as the entry point to a prebuilt framework container in Amazon SageMaker AI
- B. Rewrite the training logic as a built-in algorithm
- C. Package the script into a custom image and register it before training
- D. Move the script into a hyperparameter tuning job definition
Answer & Explanation
Correct Answer: A. Supply the script as the entry point to a prebuilt framework container in Amazon SageMaker AI
Explanation:
SageMaker provides maintained Deep Learning Containers (DLCs) for popular frameworks like PyTorch, TensorFlow, MXNet, and Hugging Face. When using Script Mode, you simply supply your Python training script (entry_point) and dependency file (requirements.txt) to the framework estimator. SageMaker pulls the prebuilt, AWS-managed container, injects your code, and executes the job—eliminating the need for your team to author Dockerfiles or manage container registries.
Why the other options are incorrect: * B. Rewrite the training logic as a built-in algorithm: SageMaker built-in algorithms (e.g., XGBoost, Image Classification, Linear Learner) are designed for standard tabular or computer vision tasks, not custom framework architecture scripts written from scratch. * C. Package the script into a custom image and register it before training: This brings-your-own-container (BYOC) approach requires building, testing, pushing, and maintaining custom Docker images in Amazon ECR, directly violating the team's constraint. * D. Move the script into a hyperparameter tuning job definition: SageMaker Automatic Model Tuning (AMT) wraps around an underlying training estimator. It does not resolve how the code/container environment itself is supplied and hosted.
AWS skills overview
In this lesson, you review the skills behind Task 2.2 as a light refresher. The nine skill statements group into four topics: running the training job itself, the hyperparameters and the search across them, generalization and combining models, and the customization work specific to generative AI. Read through them and notice which ones already feel familiar, and which ones feel shaky enough that you want to come back to them before exam day.
Running training jobs with built-in algorithms and script mode
In practice, this group of skills lets the machine learning engineer get a training job running without rebuilding the plumbing every time, and know which of the three routes into a managed job the situation calls for.
Be comfortable doing the following:
- Recognizing which built-in algorithms and common libraries suit a problem type, so a tabular regression or classification job does not become a custom implementation exercise.
- Supplying your own training script as an entry point to a prebuilt framework container, which is script mode, and knowing that the framework container is provided while the training loop stays your own code.
- Knowing that a container you build yourself remains available for a framework or dependency the prebuilt images do not cover, and that it is the heaviest of the three options to maintain.
The choice is about ownership, not capability. A built-in algorithm hands over the training code and asks only for data and hyperparameters. Script mode keeps authorship of the training loop while borrowing a maintained image. A container you build gives complete control and hands back every dependency upgrade. Some built-in offerings run in script mode internally while still supplying the script, which is worth knowing so the two terms do not blur together.
Knowledge Check
What does script mode change about a managed training job? (Choose 1)
- A. The training logic comes from a script the team supplies, running inside a container AWS maintains for the framework
- B. The service selects an algorithm automatically from the shape of the dataset
- C. Hyperparameters become fixed values that cannot be passed into the job
- D. The job stops emitting metrics that can be monitored
Answer & Explanation
Correct Answer: A. The training logic comes from a script the team supplies, running inside a container AWS maintains for the framework
Explanation:
In SageMaker Script Mode, you provide custom training scripts (e.g., PyTorch, TensorFlow, or Scikit-learn code) as an entry_point file while relying on AWS-managed Deep Learning Containers (DLCs) for the execution environment. This gives you full control over custom neural network architectures, custom loss functions, and data loading loops without requiring you to write Dockerfiles or build custom container images.
Why the other options are incorrect:
* B. The service selects an algorithm automatically from the shape of the dataset: Automatic algorithm selection and model exploration is a capability of Amazon SageMaker Autopilot (AutoML), not Script Mode.
* C. Hyperparameters become fixed values that cannot be passed into the job: In Script Mode, hyperparameters passed to the estimator are injected directly as command-line arguments (e.g., via argparse in Python), allowing for full hyperparameter customization.
* D. The job stops emitting metrics that can be monitored: Training scripts running in Script Mode output logs directly to stdout and stderr, which SageMaker automatically streams to Amazon CloudWatch. Custom training metrics can also be parsed via regular expressions defined in the estimator.
Hyperparameters, tuning, and training time
In practice, this group of skills lets the machine learning engineer treat hyperparameters as a search problem with a budget, rather than as knobs to twist until something looks better.
Be comfortable doing the following:
- Setting the fundamental hyperparameters with intent, knowing that an epoch is one pass over the training data, that batch size sets how many records contribute to each weight update, and that the learning rate governs how far the weights move per update and therefore whether the run settles at all.
- Running hyperparameter optimization as a tuning job over ranges you declare, with one objective metric, and setting completion criteria so the search stops when the budget or the quality target is met.
- Reducing training time deliberately: early stopping ends a run that has stopped improving, and distributed training spreads the work, with data parallelism splitting each batch across model replicas and model parallelism partitioning a model too large for one device.
Two mistakes recur here. The first is expecting a hyperparameter setting to be calculated. It cannot be, which is why tuning runs many training jobs and compares them against the objective metric you named. The second is confusing techniques that shorten a single run with techniques that shorten the search. Early stopping shortens a run, warm start reuses what an earlier search learned, and adding instances shortens elapsed time only while the communication between them stays cheaper than the work it saves.
Knowledge Check
How does a hyperparameter tuning job arrive at a setting? (Choose 1)
- A. It runs many training jobs across the declared ranges and keeps the combination that scores best on the objective metric
- B. It computes the optimal values in a single pass over the training data
- C. It copies the values from the most recent successful training job
- D. It adjusts the values inside one training run until the metric stops improving
Answer & Explanation
Correct Answer: A. It runs many training jobs across the declared ranges and keeps the combination that scores best on the objective metric
Explanation:
SageMaker Automatic Model Tuning (AMT) automates hyperparameter optimization (HPO) by evaluating specified ranges (integer, continuous, or categorical) over multiple training jobs. AMT uses search strategies—such as Bayesian Optimization, Random Search, or Hyperband—to evaluate model performance against a target objective metric (e.g., maximizing \(F_1\)-score or minimizing validation loss) and identifies the best-performing combination.
Why the other options are incorrect: * B. It computes the optimal values in a single pass over the training data: Hyperparameters (such as learning rate, batch size, or tree depth) govern the learning process itself; they cannot be analytically computed in a single data pass like linear regression coefficients. * C. It copies the values from the most recent successful training job: AMT systematically searches and evaluates new parameter combinations across declared search ranges rather than repeating prior job settings. * D. It adjusts the values inside one training run until the metric stops improving: Parameter updates (weights/biases) occur within a single training run via gradient descent, whereas hyperparameter tuning evaluates different configurations across separate training jobs.
Generalization, forgetting, and combining models
In practice, this group of skills lets the machine learning engineer tell the three common training failures apart, because each one is visible in a different place and each has a different remedy.
Be comfortable doing the following:
- Reading the gap between training and validation performance: overfitting shows as strong training scores with weak held-out scores, and underfitting shows as weak scores in both places.
- Naming catastrophic forgetting as its own failure, where customizing a model on a narrow domain costs it general capability it previously had, and recognizing that blending broader data into the training mixture is the usual defense.
- Combining models when it earns its place, whether that means an ensemble whose members offset one another's errors to raise performance, or hosting many models on one endpoint behind a shared serving container to raise utilization and reduce cost.
Keep the direction of the metric straight, because it decides what better means. An error metric such as mean squared error is minimized, and a score such as area under the curve is maximized, so a tuning job pointed the wrong way will faithfully optimize toward a worse model. Cost-driven consolidation has its own tradeoff too: models that share an endpoint also share memory and a serving container, so the pattern suits many similar models with tolerance for the occasional slower first request, and it does not suit a model with strict latency requirements.
Knowledge Check
A model scores well on its training data and poorly on held-out data. Which description fits that outcome? (Choose 1)
- A. The model has underfit and lacks the capacity to represent the signal
- B. The model has overfit and has learned detail specific to the training data
- C. The model has forgotten capability it held before customization
- D. The objective metric was minimized when it should have been maximized
Answer & Explanation
Correct Answer: B. The model has overfit and has learned detail specific to the training data
Explanation:
Overfitting occurs when a model memorizes noise, outliers, or specific patterns in the training dataset rather than learning generalizable features. This manifests as high performance (low error) on training data paired with poor performance (high error) on unseen, held-out validation or test datasets. Standard techniques to mitigate overfitting include adding regularization (\(L_1\)/\(L_2\)), enabling early stopping, increasing dropout, reducing model parameters, or expanding training data volume/diversity.
Why the other options are incorrect: * A. The model has underfit and lacks the capacity to represent the signal: Underfitting occurs when a model is too simplistic to learn the underlying signal, leading to poor performance on both training and held-out datasets. * C. The model has forgotten capability it held before customization: This describes catastrophic forgetting, where fine-tuning a pre-trained foundation model on a narrow dataset degrades its general capabilities, rather than a gap between training and validation set scores. * D. The objective metric was minimized when it should have been maximized: Misconfiguring an evaluation direction leads to incorrect hyperparameter selection or early stopping triggers, but does not explain a generalization gap between training and test sets.
Customizing and optimizing AI solutions
In practice, this group of skills lets the machine learning engineer improve a generative AI application in the place where the problem actually is, which is more often the retrieval than the model.
Be comfortable doing the following:
- Applying task-specific prompt engineering first, with explicit instructions, a stated output format, and a few worked examples, and treating a stored prompt with variables and versions as a change you can track and compare rather than a string buried in application code.
- Choosing a customization technique when prompting is exhausted, and matching the artifact to the technique: labeled input and output pairs for supervised fine-tuning, reward functions that score responses for reinforcement fine-tuning, and a prompt set for distillation, from which the managed path generates the teacher responses.
- Optimizing the retrieval components rather than only the generator: the embedding model that represents both documents and queries, the chunking of the source content, and the retriever that fetches and ranks what the model finally reads.
A generative AI answer has two upstream causes, and improving the wrong one wastes a cycle. If the passages the retriever returns do not contain the answer, no change to the model will invent it, so the work belongs in the embedding model, the chunking, and the ranking. If the passages are right and the answer still reads poorly, the work belongs in the prompt, and then in customization. Naming which half is failing before changing anything is the habit that separates a fix from a guess.
Knowledge Check
Retrieved passages in a generative AI application are frequently only loosely related to the question that was asked. Which change addresses that directly? (Choose 1)
- A. Revisit the embedding model and how the source documents were chunked
- B. Increase the number of tokens the model may generate
- C. Fine-tune the generating model on the same documents
- D. Lower the temperature setting used at inference
Answer & Explanation
Correct Answer: A. Revisit the embedding model and how the source documents were chunked
Explanation:
Retrieval accuracy in a Retrieval-Augmented Generation (RAG) system relies directly on the chunking strategy (chunk size, overlap, and structural boundaries) and the embedding model used to map text into vector space. If chunks are too large, semantic signal gets diluted with irrelevant noise; if chunking splits sentences arbitrarily across key context, vector representations fail to capture complete meaning. Adjusting chunking strategies (e.g., semantic or hierarchical chunking) or choosing a domain-aligned embedding model directly fixes poor vector search relevance.
Why the other options are incorrect:
* B. Increase the number of tokens the model may generate: Adjusting max_tokens controls the maximum response length produced during generation, but has zero effect on vector search retrieval precision.
* C. Fine-tune the generating model on the same documents: Fine-tuning alters LLM generation weights and output style, but does not fix poor chunk boundaries or inaccurate vector retrieval from an external vector store.
* D. Lower the temperature setting used at inference: Lowering temperature reduces generation randomness (making outputs more deterministic), but does not alter vector indexing or change which passages are retrieved.
Knowledge Check
A training job converges well and fits on a single instance, but it takes too long to finish. Which change reduces training time MOST directly? (Choose 1)
- A. Increase the number of epochs the job runs
- B. Switch the objective metric the job reports
- C. Reduce the size of the validation split
- D. Distribute the job across several instances by using data parallelism
Answer & Explanation
Correct Answer: D. Distribute the job across several instances by using data parallelism
Explanation:
When a model architecture fits entirely within a single GPU/instance memory, the training bottleneck is total throughput (compute speed over large dataset sizes). Data Parallelism (e.g., using SageMaker Distributed Data Parallel) creates identical replicas of the model across multiple compute nodes, splits the training dataset across those nodes, and synchronizes gradients across workers during backward passes. This scales throughput almost linearly, drastically reducing total training time.
Why the other options are incorrect: * A. Increase the number of epochs the job runs: Running more passes over the training dataset directly increases total execution time. * B. Switch the objective metric the job reports: Metrics monitor model performance during training; changing how loss or accuracy is reported has zero impact on compute workload or training speed. * C. Reduce the size of the validation split: While evaluating smaller validation sets slightly cuts down evaluation overhead per epoch, it provides negligible speedup compared to distributing batch processing across multiple instances.