Pretrained Models and Transfer Learning Questions

Working knowledge of pretrained models and transfer learning covers selecting, loading, adapting, and fine tuning models trained on large datasets so they can solve new tasks with limited data. Candidates should understand how to find and use model hubs and repositories such as Hugging Face, PyTorch Hub, and TensorFlow Hub, choose appropriate base models for a problem, and implement both feature extraction approaches where most weights are frozen and full fine tuning where weights are updated. The topic includes parameter efficient adaptation techniques such as adapter modules and low rank adaptation, strategies for freezing or unfreezing layers, data augmentation and domain adaptation considerations, and different optimization and regularization choices when data is scarce. It also spans domain specific practices for computer vision and natural language processing, familiarity with common pretrained sources such as ImageNet trained convolutional networks for vision and transformer based language models for text, evaluation and validation practices, compute and memory trade offs when fine tuning large models, and practical aspects like checkpointing, hyperparameter tuning, and inference deployment.

MediumTechnical

91 practiced

Implement a simple PyTorch training loop (using the Hugging Face Transformers library) to fine-tune a pretrained BERT model for sequence classification. Freeze the encoder layers and train only the classification head and LayerNorm parameters. Show how to prepare the optimizer so only trainable params are updated, and include a validation step calculating accuracy.

Sample Answer

Approach: Load a pretrained BERTForSequenceClassification, freeze all encoder params, unfreeze classifier head and any LayerNorm parameters (often named "LayerNorm" or ".layer_norm"). Build optimizer on model.parameters() filtered for requires_grad, train for epochs with standard forward/backward, and run validation computing accuracy.

python

import torch
from torch.utils.data import DataLoader
from transformers import AutoTokenizer, AutoModelForSequenceClassification, get_linear_schedule_with_warmup
from datasets import load_dataset
import torch.nn.functional as F

device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
model_name = "bert-base-uncased"

# Data (example using glue/mrpc)
dataset = load_dataset("glue", "mrpc")
tokenizer = AutoTokenizer.from_pretrained(model_name)

def preprocess(batch):
    toks = tokenizer(batch["sentence1"], batch["sentence2"], truncation=True, padding="max_length", max_length=128)
    toks["labels"] = batch["label"]
    return toks

train_ds = dataset["train"].map(preprocess, batched=True)
val_ds = dataset["validation"].map(preprocess, batched=True)
cols = ["input_ids","attention_mask","labels"]
train_dl = DataLoader(train_ds.remove_columns([c for c in train_ds.column_names if c not in cols]), batch_size=16, shuffle=True)
val_dl = DataLoader(val_ds.remove_columns([c for c in val_ds.column_names if c not in cols]), batch_size=32)

# Model
model = AutoModelForSequenceClassification.from_pretrained(model_name, num_labels=2)
model.to(device)

# Freeze all params first
for p in model.parameters():
    p.requires_grad = False

# Unfreeze classifier head and LayerNorm parameters
for name, p in model.named_parameters():
    if name.startswith("classifier") or "layernorm" in name.lower() or "layer_norm" in name.lower() or "LayerNorm" in name:
        p.requires_grad = True

# Prepare optimizer with only trainable params
trainable_params = [p for p in model.parameters() if p.requires_grad]
optimizer = torch.optim.AdamW(trainable_params, lr=2e-5, weight_decay=0.01)
total_steps = len(train_dl) * 3
scheduler = get_linear_schedule_with_warmup(optimizer, num_warmup_steps=0, num_training_steps=total_steps)

# Training loop with validation accuracy
def evaluate(model, dataloader):
    model.eval()
    correct = total = 0
    with torch.no_grad():
        for batch in dataloader:
            input_ids = batch["input_ids"].to(device)
            attention_mask = batch["attention_mask"].to(device)
            labels = batch["labels"].to(device)
            outputs = model(input_ids=input_ids, attention_mask=attention_mask)
            preds = outputs.logits.argmax(dim=-1)
            correct += (preds == labels).sum().item()
            total += labels.size(0)
    return correct / total

for epoch in range(3):
    model.train()
    for batch in train_dl:
        input_ids = batch["input_ids"].to(device)
        attention_mask = batch["attention_mask"].to(device)
        labels = batch["labels"].to(device)
        outputs = model(input_ids=input_ids, attention_mask=attention_mask, labels=labels)
        loss = outputs.loss
        loss.backward()
        optimizer.step()
        scheduler.step()
        optimizer.zero_grad()
    val_acc = evaluate(model, val_dl)
    print(f"Epoch {epoch+1} — val_acc: {val_acc:.4f}")

Key points:- Freezing reduces compute/memory and preserves pretrained features.- Ensure LayerNorm params are trainable for stability when adapting to new tasks.- Filter optimizer to only update parameters with requires_grad=True.

MediumTechnical

46 practiced

Design an A/B testing and monitoring plan for deploying a finetuned text classification model in production. Specify primary business metrics, statistical significance criteria, rollout percentage schedule, data collection for offline evaluation, and automatic rollback triggers for model quality degradation.

Sample Answer

Requirements & goals:- Improve end-to-end business outcome (reduce false positives that block customers) while maintaining latency and throughput. Preserve trust and avoid regressions.

Primary business metrics (primary + health metrics):- Primary: Conversion retention rate lift (e.g., accepted transactions / total) or reduction in manual review rate; express as relative change vs baseline.- Secondary: Precision@threshold and recall (for high-risk classes), False Positive Rate (FPR), False Negative Rate (FNR).- Health metrics: prediction latency P95, error rate, throughput, model input distribution drift (KL divergence), customer complaint volume.

A/B test design:- Randomized controlled experiment: traffic split users into Control (prod model) and Treatment (fine-tuned model) by user-id hashing; stratify by region/device if relevant.- Sample size & significance: power analysis targeting minimum detectable effect (MDE) = 2–3% relative change on primary metric; α=0.05, power=0.8. Compute sample size from baseline conversion variance; default start with N≈50k users per arm if unknown, adjust after pilot.

Rollout schedule:- Canary (1% treatment) for 24–48 hours — automated quick checks.- Ramp to 5% for 48–72 hours — more data collection.- Ramp to 20% for 3–7 days — intermediate evaluation.- Ramp to 50% for 7 days — statistical evaluation window.- Full rollout (100%) only after meeting pre-specified success criteria.

Statistical criteria:- Primary metric: two-sided test, p<0.05 and effect size > MDE; use bootstrapped confidence intervals for non-normal metrics.- Adjust for multiple comparisons if evaluating multiple segments (Benjamini-Hochberg).- Use sequential testing with alpha spending (e.g., O’Brien-Fleming) to allow interim looks without inflating Type I error.

Data collection for offline evaluation:- Log model inputs, raw model scores, calibration confidence, predicted label, ground-truth when available, timestamps, user metadata, and downstream outcome (e.g., conversion, review outcome).- Store hashes for privacy. Keep a labeled holdout set gathered via human annotation and delayed labels (e.g., outcome within 7–30 days).- Collect distribution stats (token lengths, top tokens, embedding centroid drift), and produce per-bucket confusion matrices.

Automatic rollback triggers:- Immediate rollback (stop routing to treatment) if any critical trigger: - Latency P95 exceeds baseline + 200ms or > SLA. - Error rate (exceptions) > baseline * 2. - Significant degradation in primary metric: running relative drop > MDE negative and p<0.01 over rolling 24–72h window. - FPR or FNR degrades beyond acceptable thresholds (e.g., +50% relative increase) in high-risk segments. - Data distribution shift: input feature drift > threshold (e.g., KL > 0.2) correlated with rising error.- Automated alerts to on-call, create incident, and snapshot model + data for postmortem.

Monitoring & post-deploy:- Dashboards with real-time metrics, segmented A/B comparisons, and automated daily statistical summaries.- Scheduled offline analysis: recalibrate thresholds, re-evaluate slice performance, retrain triggers.- Governance: rollout requires sign-off from ML lead + product if primary metric ambiguous.

This plan balances statistical rigor, safety (rapid rollback), and operational observability to deploy the fine-tuned classifier with controlled risk.

HardTechnical

61 practiced

You are building a finetuning workflow with explainability for stakeholders who require transparency. How would you integrate interpretability methods (attention visualization, saliency maps, SHAP/LIME), produce model cards, and handle requests to exclude or protect sensitive features? Discuss process, tooling, and team roles to operationalize explainability.

Sample Answer

Situation/Goal: We’re building a finetuning workflow for models used by stakeholders who require transparency and the ability to exclude or protect sensitive features. I’d operationalize explainability end‑to‑end so transparency is repeatable, auditable, and integrated into the ML lifecycle.

Process (high level):1. Requirements & data contracts — collaborate with product, legal, and privacy to list stakeholders’ explainability needs, regulatory constraints, and sensitive features that must be protected or excluded.2. Design pipeline hooks — instrument the finetune pipeline to emit model/version metadata, feature provenance, training/validation datasets snapshots, and explainability artifacts for each run.3. Produce explainability artifacts during CI training: attention visualizations (for transformer layers), saliency maps (vision/grad‑based), and SHAP/LIME feature attributions for tabular/text inputs. Store artifacts in the model registry with model card generation.4. Review & approval — run automated checks (bias, robustness, leakage) and human review with privacy and compliance before deployment.5. Post‑deploy monitoring — continuous checks for distribution drift and re‑compute explanations on sampled requests; alert on anomalous attributions.

Tooling:- Libraries: Captum/transformers-attention utilities for attention maps; Captum/IntegratedGradients or GradCAM for saliency; SHAP and Alibi for attributions; LIME for fast local explanations where appropriate.- Governance: Model Cards Toolkit (Google), MLflow or SageMaker model registry for metadata and artifact storage, Great Expectations for data contracts, Evidently/Fairlearn for fairness checks.- Privacy: Differential privacy libraries (Opacus, TensorFlow Privacy), feature encryption and tokenization, feature store (e.g., Feast) to control access.- Orchestration: CI/CD pipelines (GitHub Actions, Argo) that run explainability generation, automated tests, and policy checks before promotion.

Handling sensitive features:- Prevent use by policy + enforcement: maintain a feature catalog marked with sensitivity labels. The pipeline rejects training configurations that include “protected” features unless an approved exception exists.- If stakeholders ask to “exclude” sensitive attributes: implement strict exclusion at feature‑engineering and model input layers and add tests to ensure no leakage via proxies (use correlation/proxy detection and counterfactual fairness checks).- For “protect” rather than exclude: apply techniques like adversarial debiasing, representation learning with orthogonalization to protected features, or DP to limit memorization.- Keep an audit trail of decisions, approvals, and mitigation applied.

Team roles and responsibilities:- AI Engineer (me): implement explainability methods in finetune scripts, ensure reproducible artifact generation, integrate with registry.- ML Engineer/MLOps: pipeline orchestration, model registry, CI, monitoring, reproducible runs.- Data Scientist: design appropriate attribution methods, validate explanations, run bias and proxy analyses.- Privacy/Legal/Compliance: define sensitive features, approve exceptions, validate privacy controls.- Product Manager/Stakeholder: define transparency requirements, review model cards and human‑readable explanations.- Security: control access to sensitive artifacts and PII in explainability outputs.

Deliverables and governance:- Automated model card per build (purpose, data, metrics, top feature attributions, limitations, mitigation steps).- Explainability report: global attributions, representative local explanations, attention heatmaps/saliency examples, fairness metrics and mitigation applied.- Audit logs and reproducible run IDs linked to artifacts.- SLA: timeframe for explanation requests and process for ad‑hoc deeper investigations.

Why this works:- Embeds explainability into the lifecycle (not ad‑hoc)- Uses complementary explanation techniques — attention/saliency for model internals, SHAP/LIME for actionable feature attributions- Enforces policy via feature catalog, automated checks, and human approvals- Balances transparency with privacy by using controlled artifacts, DP, and proxy detection

Example outcome:For a finetuned credit‑scoring model we produced a model card showing top SHAP drivers, attention visualizations for text inputs that led to decisions, and documented that “race” and its proxies were excluded; an automated proxy detector flagged two correlated features and we applied orthogonalization plus re‑evaluation before approval.

MediumTechnical

94 practiced

Compare AdamW and Adafactor optimizers for fine-tuning large pretrained models. Discuss memory characteristics, when Adafactor is preferred, stability and hyperparameter choices, and how optimizer choice affects learning rate schedules for large LMs.

Sample Answer

High-level comparison:- AdamW: standard, per-parameter first/second moment estimates (m, v), well-understood convergence and stability for fine-tuning. Memory: 2 extra tensors per param (m and v) -> ~2× model size. Hyperparams: typical defaults (lr 1e-5–5e-5 for LMs, β1=0.9, β2=0.999, eps ~1e-8) work well.- Adafactor: reduces memory by using factored second-moment estimates (row/column factors) or optionally no-explicit v at all -> memory can be O(sqrt(n)) per matrix rather than O(n), often ~replaces v so <2× overhead. Designed for very large models where optimizer state is bottleneck.

When to prefer Adafactor:- Fine-tuning billion+ parameter models on limited GPU/TPU memory, or when checkpoint/FP16 memory pressure from AdamW state prevents desired batch size or longer context.- Large pretraining runs where lower optimizer memory is crucial.

Stability and hyperparameter choices:- Adafactor can be less stable with default aggressive step sizes; need learning rate scaling and often use relative step size (Adafactor’s relative_lr flag) or manual lr schedules. Use clipping (grad_norm), weight decay, and eps tuning. For AdamW, keep smaller lr and warmup; AdamW is more forgiving of defaults.- For Adafactor, set beta parameters carefully or use its default momentum-disabled variant with careful lr (e.g., relative lr ~1e-2–1e-3) and longer warmup.

Effect on learning-rate schedules:- AdamW + LMs: common to use conservative constant+linear-warmup-decay or cosine with short warmup (e.g., 500–2000 steps) and small peak lr. Adam’s internal moments interact with lr—less aggressive schedules preferred.- Adafactor: often paired with relative step sizes and larger absolute lr ranges because second-moment estimation differs; requires longer warmup and sometimes no decay or cosine decay tuned empirically. Because Adafactor adapts differently, monitor loss and scale lr by batch size and sequence length; use more conservative clipping and validation checks.

Practical guidance:- If memory permits, use AdamW for stability and fewer hyperparameter tweaks.- If memory is the constraint, use Adafactor with relative learning rate, careful warmup, gradient clipping, and validate with small sweep of lr and eps. Keep checkpoints of optimizer state when possible and consider mixed precision + ZeRO or sharding as alternatives to switching optimizers.

EasyTechnical

79 practiced

For a finetuning job with limited labeled data, list the top hyperparameters you would tune (at least five) and explain for each why it matters in low-data scenarios. Include learning rate, weight decay, batch size, number of epochs, and data augmentation intensity in your discussion.

Unlock Full Question Bank

Get access to hundreds of Pretrained Models and Transfer Learning interview questions and detailed answers.

Join thousands of developers preparing for their dream job.