ML Model and Foundation Model (FM) Development practice questions

RAG grounds a model in documents retrieved at query time, which suits frequently changing knowledge and answers that need citations.

Two requirements decide it: knowledge that changes weekly and answers that cite their source. A Bedrock knowledge base retrieves the relevant policy chunks for each question and returns citations, and a data source sync keeps it current with no model training. Fine-tuning and continued pre-training both bake a snapshot of the policies into the weights, go stale between runs and cannot point to a source. Hand-maintained prompt summaries are fragile and uncited.

1. Note that the facts change frequently.
2. Note that answers need a traceable source.
3. Recall that RAG retrieves current documents at query time and returns citations.
4. Reject options that store knowledge in model weights.

Exam tip: Changing facts plus citations points to RAG, not fine-tuning.

Model distillation transfers a large teacher model's behaviour on a specific task to a smaller, faster student model, using the teacher's own responses as training data.

The constraints are prompts without reference answers and no scoring logic. Bedrock Model Distillation needs exactly what the team has: use-case prompts (or invocation logs) plus a teacher whose accuracy is acceptable. It generates teacher responses and fine-tunes the student on them. Supervised fine-tuning needs labeled pairs, reinforcement fine-tuning needs a reward function, and Provisioned Throughput keeps the same expensive model.

1. Identify the goal: the large model's accuracy at lower latency and cost.
2. Inventory the data: prompts only, no labels, no grader.
3. Match the data to the method: distillation uses teacher responses as labels.
4. Reject methods that need labels or a reward function.

Exam tip: Good teacher, prompts but no labels, need smaller and faster: distill.

Reinforcement fine-tuning improves a model from feedback produced by a reward function, so it fits tasks where outputs can be scored automatically but correct answers were never written down.

There are no labeled reference programs, which rules out supervised fine-tuning on real examples, but an automatic grader exists. Reinforcement fine-tuning in Amazon Bedrock takes training prompts and a reward function (for example in AWS Lambda), so the compile-and-test pass rate becomes the learning signal. Supervised fine-tuning is the near-twin, but manual excerpts are not examples of correct programs. Distillation is tempting because it needs no labels, but a student can only be as good as its teacher, and no available teacher knows the language. Better retrieval ranking does not fix generation errors.

1. Check what supervision exists: no labeled solutions.
2. Check what feedback exists: an automatic pass rate.
3. Map automatic scores to reinforcement fine-tuning with a reward function.
4. Reject distillation because no teacher performs well on this task.

Exam tip: No labels but an automatic scorer: reinforcement fine-tuning with a reward function.

Parameter-efficient fine-tuning (PEFT) such as LoRA trains a small set of added weights while the base model stays frozen.

Two constraints decide it: limited GPU budget and a separate variant per task without three full copies. LoRA trains low-rank adapters, so training needs far less memory and compute than updating every weight, and each task's result is a small adapter that loads onto one shared base model. Full-parameter fine-tuning fails the budget and the storage constraint; a single combined model fails the per-task requirement; domain adaptation solves a different problem.

1. Note the budget constraint on training compute.
2. Note the need for per-task variants without full copies.
3. Recall that PEFT freezes the base and trains small adapters.
4. Choose one adapter per task on a shared base model.

Exam tip: Many task variants on a tight GPU budget: LoRA adapters on one frozen base model.

Structured, labeled, tabular prediction problems are best served by traditional supervised ML, not generative models.

The data is tabular, labeled with the outcome, and large, and the output is a probability per subscriber every night. A supervised gradient-boosted tree model fits exactly this pattern. A foundation model is the tempting modern choice, but prompting it per row is expensive, slow and ignores the labeled history. Comprehend works on text, and clustering ignores the labels.

1. Identify the data type: labeled tabular rows.
2. Identify the output: a probability per subscriber, in bulk.
3. Map that to supervised tabular ML such as gradient-boosted trees.
4. Reject generative and unsupervised options.

Exam tip: Labeled tabular prediction at volume: traditional supervised ML, not an FM.

Interpretability requirements can rule out more accurate models: intrinsically interpretable models such as linear or logistic regression expose their logic directly as coefficients.

Two facts combine. The requirement is a fixed, published weight per feature, which is what a linear model's coefficients are, and the accuracy gap is small (0.81 vs 0.80 AUC). Each XGBoost option looks workable but misses part of the requirement: SHAP values from SageMaker Clarify are per-prediction attributions that vary by applicant, a global importance ranking has neither direction nor size, and monotonic constraints guarantee direction only, not a constant effect size. Only the logistic regression model gives one weight that applies to everyone.

1. Read the requirement literally: one fixed weight per feature for everyone.
2. Recognise that as a linear model's coefficients.
3. Weigh the accuracy difference: 0.01 AUC.
4. Check each explainability add-on for XGBoost: per-prediction (SHAP), unsigned (importance) or direction-only (monotonic constraints).

Exam tip: A required global, fixed weight per feature means an intrinsically interpretable linear model; SHAP, importance and monotonic constraints do not provide it.