Generative AI and Large Language Models Questions
The capabilities and behavior of modern generative and large language models. Covers how LLMs are pretrained, in-context learning and few-shot prompting, generative model families (autoregressive, diffusion), context windows, and tokenization and sampling. Emphasizes understanding what generative models can and cannot do and how they differ from discriminative ML.
At a high level, describe diffusion generative models: what are the forward (noising) and reverse (denoising) processes, how is the model trained, and how does sampling work at generation time? Give an example use case where diffusion is preferred over GANs.
Sample Answer
Direct answer
Diffusion models generate data by learning to reverse a gradual noising process: a fixed forward process progressively adds Gaussian noise to real data over many steps until it becomes indistinguishable from pure noise, and the model learns the reverse process, predicting the noise (or an equivalent quantity) at each step so that starting from pure noise and iteratively denoising produces a realistic sample.
Structured elaboration
Forward (noising) process. Starting from a real data point x0, Gaussian noise is added in small increments over T steps according to a fixed noise schedule βt, producing progressively noisier versions x1,x2,…,xT, until xT is essentially pure noise with no remaining signal from x0. This process has no learned parameters; it's a fixed, known mathematical procedure.
Reverse (denoising) process. The model learns to approximate the reverse: given a noisy xt, predict either the noise that was added to produce it, or directly the mean of the slightly-less-noisy xt−1. At generation time, you start from pure noise xT and repeatedly apply the learned reverse step, T times, gradually removing noise until you arrive at a sample x0 that looks like it came from the real data distribution.
Training objective. The most common formulation trains the model to predict the noise ϵ that was added at a randomly sampled step t, using a simple mean-squared-error loss between the predicted and true noise. This is mathematically equivalent (up to a reweighting) to optimizing a variational lower bound on the data likelihood, but the simplified noise-prediction MSE objective is what's used in practice because it trains more stably and produces better samples than directly optimizing the full likelihood bound.
Why Gaussian noise and reweighted objectives. Gaussian noise is used because it has convenient closed-form properties (you can jump directly from x0 to any noisy xt in one step during training, without simulating all the intermediate steps, since the sum of the individually-added Gaussian noise steps is itself Gaussian). The training objective is typically reweighted across timesteps (rather than using the literal variational-bound weighting) because empirically it puts more training emphasis on the timesteps that matter most for final sample quality, which the raw likelihood bound underweights.
Diffusion versus GANs, an example use case. Diffusion is generally preferred over GANs when sample quality and diversity matter more than generation speed, and when training stability is a priority, e.g., a text-to-image product where users are willing to wait a few seconds for a high-quality, varied image, versus a real-time application (live video style transfer) where a GAN's single-forward-pass speed is the deciding factor even at some cost to quality or diversity.
Trade-offs & pitfalls
The biggest practical cost of the diffusion formulation is sampling speed: generating one sample requires running the learned reverse step many times (historically hundreds to a thousand steps, though modern fast samplers have brought this down substantially), which is fundamentally more expensive at inference time than a GAN's single forward pass. A common misunderstanding is treating the number of diffusion steps as purely a quality knob you can freely increase; beyond a point, more steps mostly add latency without meaningfully improving sample quality, and the practical tuning is finding the fewest steps that preserve acceptable quality for the specific application.
Explain scaling laws for language models: how do model size, dataset size, and compute budget influence loss and generalization? What are the practical consequences for dataset preparation, model selection, and cost estimates when planning to train an LLM?
Sample Answer
Direct answer
Scaling laws describe how a language model's loss decreases predictably as you increase model size, dataset size, or training compute, following an approximately power-law relationship; the practical consequence is that, for a fixed compute budget, there is a compute-optimal balance between model size and dataset size, and simply making the model as large as possible while using whatever data happens to be available is generally NOT compute-optimal.
Structured elaboration
The basic relationship. Loss L decreases roughly as a power law in each of model parameters N, dataset size D, and compute C, when the other two are not the bottleneck: L(N)∝N−α, and similarly for D and C, with empirically fitted exponents. The key practical insight (established by later scaling-law work, notably Chinchilla) is that model size and dataset size should be scaled together, not independently; a model that is very large but trained on comparatively little data is typically "undertrained" relative to what its parameter count could support, and would have achieved lower loss for the same compute budget with a smaller model trained on proportionally more data.
Compute-optimal training. For a fixed compute budget C≈6ND (a standard approximation for training FLOPs as roughly six times parameters times tokens), there is a specific (N,D) pair that minimizes loss for that budget; empirically, compute-optimal scaling calls for roughly comparable growth in both parameters and training tokens as compute increases (both should grow, not just one), rather than the earlier practice of scaling parameters aggressively while holding dataset size comparatively fixed.
Worked example
Given a fixed compute budget of 6×1023 FLOPs, and using the approximation C≈6ND, a team deciding purely by "make it bigger" might train a 50B-parameter model on 400B tokens: 6×5×1010×4×1011=1.2×1023 FLOPs, well under budget, so they'd push the model size up further, say to 100B parameters on the same 400B tokens: 6×1011×4×1011=2.4×1023 FLOPs, still under the 6×1023 budget, and might keep growing the model to "use up" the compute. A compute-optimal allocation instead grows BOTH: for example, roughly a 25B-parameter model on 4 trillion tokens hits close to the same 6×1023 budget (6×2.5×1010×4×1012=6×1023), and empirical scaling-law findings show configurations closer to this balanced allocation achieve LOWER loss for the identical compute spend than the parameter-heavy, data-light allocation, because the very large, undertrained model in the first scenario was leaving loss improvement on the table that more data would have captured more cheaply than more parameters would.
Trade-offs & pitfalls
Scaling laws give you the compute-optimal TRAINING allocation, but training compute isn't the only cost that matters in production: a smaller model trained compute-optimally on more data is also cheaper to SERVE (lower inference latency and cost per query, which recurs on every single request, unlike training cost which is paid once). This means the genuinely optimal choice for a product often deliberately trains a smaller-than-compute-optimal model on even more data than the pure training-compute-optimal point would suggest, intentionally "overtraining" relative to the scaling-law optimum, because the resulting inference savings over the product's lifetime outweigh the extra training cost. A common mistake is treating the compute-optimal training point as the final answer without separately accounting for this inference-cost dimension, which the classic scaling-law framing (focused purely on training-loss-per-training-FLOP) doesn't include.
Design a data-collection pipeline and rater interface for gathering pairwise human-preference judgments to train a reward model. Cover UI elements (randomized presentation order, clear instructions with examples, a tie option, progress indicators, and gold/calibration checks), sampling strategy for which outputs to compare and how many comparisons per prompt to target, quality-control measures and agreement thresholds, storage formats, and how UI choices themselves can introduce label bias.
Sample Answer
Direct answer: A good preference-data-collection pipeline pairs a well-designed rater interface (clear side-by-side comparison, a tie option, and calibration checks) with a sampling strategy that prioritizes informative pairs, and layers quality control (gold examples, agreement thresholds) on top so noisy labels do not silently degrade the reward model.
Structured elaboration:
- UI elements: present the prompt/context once, then the two candidate outputs side by side with a prominent choice control and keyboard shortcuts for speed, include an explicit tie or "no preference" option (forcing a choice when raters are genuinely uncertain injects noise), show progress indicators and keep each task batch short (roughly 3-5 pairs) to limit fatigue, and interleave a small number of known gold-labeled pairs so raters get real-time calibration feedback.
- Sampling strategy: start with a stratified baseline across prompt types, model families, and difficulty levels so the dataset has broad coverage, then layer active sampling on top, prioritizing pairs where the current reward model's predicted scores for the two candidates are close together (high uncertainty) or where different candidate-generating models disagree strongly, since these pairs carry the most information per label; keep a deliberate slice (for example around 20%) of purely random sampling so the active-learning loop does not create blind spots by only ever labeling near its own current decision boundary.
- Quality control: insert gold-labeled examples into a percentage of every annotator's task stream (rotated so they cannot be memorized) to calibrate and catch quality drops in real time; use redundancy, multiple independent raters per pair, escalating from a base level (for example 3 raters) to more raters or expert adjudication specifically for pairs where initial agreement is low, rather than applying high redundancy uniformly and wasting labeling budget on easy, unambiguous pairs; require a minimum agreement threshold (for example majority agreement, or Cohen's kappa above a set bar) before a labeled pair is included in reward-model training, with a stricter bar for anything safety-relevant.
- Storage: store each annotation event as an immutable record capturing the prompt, both candidates, the annotator's choice, a tie flag, timing information, which gold/calibration checks applied, and the model versions that generated the candidates, so every training example is fully traceable back to its provenance for later audits or dataset-version comparisons.
Worked example: A concrete cost-quality trade-off: if simple majority-of-3 agreement is only around 60% on a given pair, escalating that specific pair to 5 raters (or an expert adjudicator) rather than escalating the ENTIRE dataset to 5-rater redundancy keeps the average cost per label close to the 3-rater baseline while still resolving the genuinely ambiguous pairs correctly, this adaptive-redundancy approach typically costs far less than uniform high redundancy while catching most of the same disagreement cases, since most pairs are not actually ambiguous.
Trade-offs and pitfalls: Higher uniform redundancy increases label reliability but multiplies cost linearly with every additional rater per pair, which is why adaptive (uncertainty-triggered) redundancy is usually the better default; conversely, setting the agreement threshold for inclusion too low lets noisy, low-consensus labels leak into reward-model training, which is a direct path to the annotator-bias and reward-hacking problems discussed elsewhere in this pipeline. UI choices themselves can introduce bias, for example if candidate A always appears on the left, position bias can creep into the labels, so randomizing left/right placement is not a cosmetic detail but a genuine label-quality control.
Compare Generative Adversarial Networks (GANs), Variational Autoencoders (VAEs), and diffusion models at a high level: the generation process, sample quality versus diversity trade-offs, training stability, and typical application domains.
Sample Answer
Direct answer
GANs, VAEs, and diffusion models are three different ways to learn a generative process for the same broad goal, producing realistic samples from a target data distribution, and each makes a different trade-off between sample quality, diversity, and training stability. GANs pit a generator against a discriminator in an adversarial game; VAEs learn an encoder-decoder pair with an explicit probabilistic latent space; diffusion models learn to gradually denoise pure noise back into data through many small steps.
Structured elaboration
GANs (Generative Adversarial Networks). A generator network maps random noise to a candidate sample, and a discriminator network tries to tell real data apart from the generator's output; the two are trained adversarially (the generator tries to fool the discriminator, the discriminator tries not to be fooled), and at equilibrium the generator produces samples indistinguishable from real data. GANs are notorious for training instability (the adversarial dynamic can oscillate or collapse rather than converge) and for mode collapse, where the generator learns to produce only a narrow subset of plausible outputs because that subset is enough to fool the current discriminator, sacrificing diversity for sample quality.
VAEs (Variational Autoencoders). An encoder maps input data to a distribution over a latent space (rather than a single point), and a decoder maps a sample from that latent distribution back to data space; the model is trained to both reconstruct the input well and keep the latent distribution close to a simple prior (typically a standard Gaussian), via the evidence lower bound (ELBO) objective. VAEs train stably (a single well-behaved loss, no adversarial dynamics) but tend to produce blurrier, lower-fidelity samples than GANs or diffusion models, a well-documented consequence of the reconstruction term in the ELBO objective favoring averaged, "safe" outputs over sharp, high-frequency detail.
Diffusion models. A forward process gradually adds Gaussian noise to real data over many steps until it becomes pure noise; the model is trained to reverse this, predicting (at each step) either the noise that was added or the denoised data, so that starting from pure noise and running the learned reverse process many times produces a realistic sample. Diffusion models currently produce the highest sample quality and diversity of the three (state of the art for image and audio generation as of recent years) and train more stably than GANs, since the training objective is a straightforward denoising prediction loss rather than an adversarial game, but generation is comparatively slow, since producing one sample requires many sequential denoising steps rather than a single forward pass.
Sample-quality-versus-diversity and training-stability summary. GANs: potentially very sharp samples, but real risk of mode collapse (low diversity) and unstable training. VAEs: stable training, easy to sample from, but characteristically blurrier output. Diffusion: currently the best combination of quality and diversity, and stable to train, at the cost of much slower sampling (many sequential steps per sample) compared to a GAN's single forward pass.
Typical application domains. GANs remain popular where fast, single-pass generation matters (real-time style transfer, some image-editing tools) and where their sharper output is valued despite the training-stability cost. VAEs are common where a smooth, structured, and easily-interpolatable latent space matters more than photorealistic fidelity, e.g., representation learning, anomaly detection, controlled generation via latent-space manipulation. Diffusion models dominate current state-of-the-art image and audio generation products, where output quality is the priority and the slower sampling cost is acceptable or mitigated with fewer-step samplers.
Trade-offs & pitfalls
It's tempting to treat diffusion as a strict replacement for the other two given its current quality lead, but the slow, multi-step sampling cost is a real production constraint: a GAN's single forward pass can be orders of magnitude faster at inference time than a multi-step diffusion sampler, which matters directly for latency-sensitive applications. The practical decision is rarely "which family is best" in the abstract, but which family's specific trade-off, sampling speed versus sample quality versus training stability, matches the product's actual constraints.
Define emergent abilities in LLMs and give two concrete examples where a capability appears only above a certain model scale. Why do emergent phenomena complicate safety testing and capability guarantees for production systems?
Sample Answer
Direct answer
An emergent ability is a capability that appears sharply once a model crosses a certain scale threshold, essentially absent or near-random below that threshold and suddenly substantially above chance above it, rather than improving smoothly and predictably alongside overall training loss. Two commonly cited examples are multi-step arithmetic, where small models perform near chance and larger models past a certain size suddenly perform well, and certain forms of multi-step reasoning that chain-of-thought prompting only reliably helps once a model is large enough to make productive use of the intermediate steps.
Structured elaboration
Why this is surprising. Overall training loss decreases smoothly and predictably with scale, following the scaling-law relationships. You would naively expect every downstream capability to improve just as smoothly alongside it. Emergent abilities are notable specifically because a smoothly improving loss curve can hide a sharply discontinuous jump in one particular downstream capability, a jump that isn't visible at all if you're only watching the aggregate loss metric.
Why emergent phenomena complicate safety testing and capability guarantees. If you evaluate a model at one scale and it lacks a certain capability, or a certain failure mode, you cannot safely assume the next larger model in the same family will behave similarly, because some capabilities, and some failure modes, can appear suddenly rather than gradually as scale increases. This means safety and capability evaluations performed on a smaller or earlier checkpoint don't reliably extrapolate to a larger successor model: a capability that seemed entirely absent, whether beneficial or actively risky, could appear abruptly at the next scale point. A testing regime built on the assumption of smooth extrapolation will systematically miss this, and a team that safety-tested a smaller model and found no evidence of a concerning behavior cannot conclude a larger successor is equally safe by simple extrapolation from that result.
Trade-offs & pitfalls
There is active debate in the field about how much of "emergence" is a genuine property of the underlying capability versus an artifact of the specific metric used to measure it. Some analyses have shown that switching from a discontinuous metric, such as exact-match accuracy, which jumps from 0 to 1 the moment the model gets an answer exactly right and gives zero credit otherwise, to a smoother, partial-credit metric on the SAME underlying task can make the apparent "emergence" look far more gradual. This matters practically: before concluding a capability has genuinely emerged, with the safety implications that carries, it's worth checking whether the discontinuity is a real property of the model's behavior or an artifact of measuring with an all-or-nothing metric that couldn't show partial progress even if the underlying capability had actually been improving smoothly all along.
Unlock Full Question Bank
Get access to all 37 Generative AI and Large Language Models interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.