Grade 12 AI & Computer Science Practice Questions — Set 8

ExplanationThe pipeline's 40-minute total run time splits into a strictly serial portion (checkout, build, packaging, deploy = 8 minutes) and a parallelizable portion (the test suite = 32 minutes), so the serial fraction is 8/40 = 0.2 and the parallelizable fraction is 32/40 = 0.8. Amdahl's Law gives the speedup achievable with N parallel workers as S(N) = 1 / (serial fraction + parallelizable fraction / N). Meeting a 10-minute target starting from a 40-minute baseline requires a speedup of S(N) = 40/10 = 4. Setting 1/(0.2 + 0.8/N) = 4 gives 0.2 + 0.8/N = 0.25, so 0.8/N = 0.05, and N = 0.8/0.05 = 16. Checking this directly: with 16 runners the test suite takes 32/16 = 2 minutes, and total pipeline time is 8 + 2 = 10 minutes, exactly meeting the target. With only 15 runners, test time is 32/15 ≈ 2.13 minutes, pushing the total to about 10.13 minutes — just over budget — so 16 is the smallest integer number of runners that works. Dividing the whole 40-minute baseline by the 10-minute target and ignoring the fixed 8-minute serial stage understates the requirement, since no amount of parallelism can shrink the serial stage itself. Using 8 runners cuts test time to 4 minutes but still totals 12 minutes, missing the target — a direct illustration of Amdahl's Law capping achievable speedup once the serial portion dominates. Using 20 runners does bring the total under 10 minutes (8 + 1.6 = 9.6 minutes) but commits more parallel test capacity than the minimum needed to hit the target.

ExplanationStandard attention costs 4N²d FLOPs and linear attention costs 4Nd² FLOPs per head, as derived from the matrix-multiply dimensions given. Linear attention is cheaper exactly when 4Nd² < 4N²d; dividing both sides by the positive quantity 4Nd leaves d < N. With d = 64, this means N must be strictly greater than 64, so the smallest integer satisfying the inequality is N = 65. The arithmetic confirms this: at N = 64 the two costs are exactly equal, 4·64²·64 = 4·64·64² = 1,048,576 FLOPs each, so N = 64 is a tie, not a strict win for linear attention — ruling that choice out. At N = 65, standard attention costs 4·65²·64 = 1,081,600 FLOPs while linear attention costs 4·65·64² = 1,064,960 FLOPs, which is strictly less, confirming N = 65 as the true crossover point. Doubling the head dimension to N = 128 comes from the common error of equating only the QKᵀ cost (2N²d) against the full linear-attention cost (4Nd²) instead of comparing full totals to full totals, and N = 4096 mistakes a popular "long-context" figure for a derived quantity rather than solving the inequality at all. The underlying lesson is that the crossover sits exactly at N = d: linear-attention variants such as Performers or RetNet-style linear recurrences only pay off once the sequence clearly outgrows the head dimension, since for short sequences the repeated construction and reuse of the d×d summary state costs more than simply forming the smaller N×N attention matrix directly.

ExplanationCount the configurations available at each intermediate node separately, then combine the three nodes' counts by multiplication, because the choice made at one node does not restrict the choices available at another — every combination of per-node choices produces a genuinely distinct cell. Node 1 has only the 2 input nodes as predecessors, so selecting the (unordered) pair of edges to keep is C(2,2) = 1 way. Each of the 2 kept edges independently receives one of K = 3 operations, giving 3² = 9 operation assignments. Node 1 therefore contributes 1 × 9 = 9 configurations. Node 2 has 3 predecessors (2 inputs plus node 1). Choosing an unordered pair of edges from 3 predecessors is C(3,2) = 3 ways; combined with 3² = 9 operation assignments, node 2 contributes 3 × 9 = 27 configurations. Node 3 has 4 predecessors (2 inputs plus nodes 1 and 2). Choosing 2 of 4 predecessors is C(4,2) = 6 ways; combined with 9 operation assignments, node 3 contributes 6 × 9 = 54 configurations. Since a full cell architecture is specified by simultaneously fixing the choice at node 1, the choice at node 2, and the choice at node 3, and these choices don't interfere with each other, the multiplication principle applies: total architectures = 9 × 27 × 54 = 13,122. This computation is precisely why real NAS systems never enumerate the search space directly: even this toy 3-node, 3-operation cell already has over 13,000 candidates, and DARTS's actual search space (4 intermediate nodes, around 8 candidate operations, plus a separately searched reduction cell) works out to roughly 10^18 architectures — far too many to train one at a time. That combinatorial blow-up is the real motivation for weight-sharing supernets and gradient-based relaxations such as DARTS's softmax-over-operations trick, which let a single training run approximate the best architecture instead of retraining every candidate from scratch — much the way ISRO's mission-planning teams evaluate a handful of high-fidelity trajectory simulations to stand in for an intractably large space of possible launch windows, rather than simulating every one individually.

ExplanationSymmetric INT8 quantization first fixes a scale factor s from the calibration range and the usable integer levels. With max|w| = 12.7 mapped onto the largest usable level 127 (keeping -128 unused so zero is exactly representable), s = 12.7 / 127 = 0.1. This step size s is the spacing between any two adjacent representable dequantized values: ..., 5.2, 5.3, 5.4, ... To quantize w = 5.34: divide by the scale, w/s = 5.34 / 0.1 = 53.4, then round to the nearest integer level, giving 53 (53.4 is closer to 53 than to 54, so there is no tie to break). Dequantizing multiplies back by the scale: 53 × 0.1 = 5.3. The reconstructed value for this specific weight is therefore 5.3, with an error of |5.34 − 5.3| = 0.04 for this particular weight. The question also asks for the *worst case* over the entire tensor, not just this one weight. Rounding to the nearest integer level can never push a value further than half a step away from its true value — if it were off by more than s/2, the *other* neighboring level would have been the nearer one and would have been chosen instead. So the tensor-wide maximum possible error is bounded by s/2 = 0.1/2 = 0.05, achieved only when a true value lands exactly halfway between two levels (e.g. x = 5.35). This half-step bound is precisely why INT4 quantization (fewer levels, larger s) trades a bigger worst-case error for a 2x smaller memory footprint than INT8, and why binary networks push that trade-off to its extreme.

ExplanationBoth text embeddings are unit vectors, since 0.8² + 0.6² = 1 and 0.6² + 0.8² = 1, so their dot products with I₁ = (1, 0) are plain cosine similarities: sim(I₁, T₁) = (1)(0.8) + (0)(0.6) = 0.8, and sim(I₁, T₂) = (1)(0.6) + (0)(0.8) = 0.6. CLIP does not softmax raw cosine similarities — it first divides by the temperature τ, which sharpens the distribution (this is exactly why India's UPI fraud-detection and IRCTC recommendation-style retrieval systems tune a temperature: it controls how confidently the model commits to its top match). With τ = 0.2, the logits become 0.8 / 0.2 = 4.0 and 0.6 / 0.2 = 3.0. Because the batch has only two texts, the softmax cross-entropy reduces to a sigmoid: with logit gap Δ = 4.0 − 3.0 = 1.0, P(T₁ | I₁) = e⁴/(e⁴ + e³) = 1/(1 + e⁻¹) = 1/(1 + 0.367879) = 0.731059. The contrastive loss is the negative log of this probability: L = −ln(0.731059) = ln(1 + e⁻¹) ≈ 0.313. Each distractor is a specific, common implementation slip. Skipping the τ-division and softmaxing 0.8 and 0.6 directly (Δ = 0.2) gives P = 1/(1 + e⁻⁰·²) = 0.549834 and loss ≈ 0.598 — a flatter, under-confident loss because the temperature sharpening was never applied. Computing 1 − P(T₁|I₁) = 1 − 0.731059 ≈ 0.269 confuses "probability of picking the wrong caption" with cross-entropy loss, which must use a logarithm, not a linear complement. Scoring against T₂ instead of the true label T₁ gives −ln(1 − 0.731059) = −ln(0.268941) ≈ 1.313, which is the loss for a completely different (wrong) target and happens to equal 1 + 0.313 purely because ln(1 + eˣ) = x + ln(1 + e⁻ˣ), a numerical coincidence of the sigmoid identity, not evidence of correctness. Only dividing by τ before softmax and then taking the negative log of the true label's probability matches how CLIP's InfoNCE loss is actually defined.

ExplanationWrite the dot product as q·k = Σ_{i=1}^{64} q_i k_i. Since each q_i and k_i has mean 0, variance 1, and all components are independent, every term q_i k_i has mean E[q_i]E[k_i] = 0 and variance E[q_i²]E[k_i²] = 1·1 = 1. Summing 64 independent terms adds their variances (not their standard deviations, and not their squares), so Var(q·k) = 64 · 1 = 64, giving a standard deviation of √64 = 8. As d_k grows, this standard deviation grows too, so raw scores can become large in magnitude; feeding large-magnitude logits into softmax pushes its output toward a near one-hot vector, where the gradient with respect to the inputs is close to zero almost everywhere — softmax saturation, which stalls learning. Dividing the dot product by √d_k = 8 rescales it to unit variance again, independent of how large d_k is, keeping the pre-softmax logits in a range where softmax's gradient stays informative. The correction must be √d_k rather than d_k because variance scales with the square of the divisor: dividing a sum of variance 64 by a constant c changes its variance to 64/c², and only c = √64 = 8 restores that to 1. Dividing by 64 instead would shrink the variance to 64/64² = 1/64, over-compressing the scores rather than restoring unit variance — the opposite failure mode. The scaling is also not about matching the numerical scale of the value vectors V; V's scale is set independently by the learned projection matrix, and the √d_k factor exists purely to counteract the variance growth of the dot product itself, keeping softmax's gradient well-behaved as d_k varies.

ExplanationFull fine-tuning of W ∈ R^(4096×4096) requires updating every entry, so the trainable parameter count equals d·k = 4096 × 4096 = 16,777,216. LoRA instead freezes W and learns a low-rank correction ΔW = BA, where B ∈ R^(4096×8) contributes d·r = 4096×8 = 32,768 parameters and A ∈ R^(8×4096) contributes r·k = 8×4096 = 32,768 parameters, for a total of r(d+k) = 8×8192 = 65,536 trainable parameters. Dividing gives 16,777,216 / 65,536 = 256, so LoRA trains 256 times fewer parameters for this matrix, even though multiplying B and A together still produces a full-sized d×k update (of rank at most 8) that gets added to the frozen W. Three errors are worth flagging explicitly. Counting only A (or only B) and ignoring that both factor matrices are trainable undercounts the parameters to 32,768 and overstates the savings as 512×; B being initialized to zero is a training-stability trick, not a reason it lacks a gradient. Assuming rank r shrinks both matrix dimensions to r×r (giving 64 parameters) confuses the rank of the update with the shape of the factor matrices — B and A still have one full-size dimension each (4096), which is exactly why they can reconstruct a 4096×4096 update. Assuming no savings occur because BA reconstructs a full-sized matrix conflates the size of the resulting update ΔW with the number of independent trainable values (in B and A) that generate it — the whole point of low-rank factorization is that far fewer numbers determine a full-sized matrix once its rank is constrained.

ExplanationA transformer's computation per generated token is bounded by its depth: with L = 12 layers, a single forward pass can chain at most 12 sequential nonlinear transformations, so a zero-shot answer token has access to at most 12 rounds of sequential reasoning — not enough for a task whose correct output provably requires D = 50 sequentially dependent steps, since each step of the orbital-correction recurrence depends on the result of the previous one. Chain-of-thought prompting works around this bottleneck by letting the model write intermediate results out as tokens. Generating the k-th CoT token requires a completely new forward pass through all 12 layers, this time conditioned on the previous k − 1 tokens, so it effectively continues the computation from where the last token left off. After T reasoning tokens, the model has had access to up to L × T = 12T sequential computation steps. To guarantee enough depth for the 50-step recurrence, we need 12T ≥ 50, i.e. T ≥ 50/12 ≈ 4.17. Because T must be a whole number of tokens, T = 4 falls short (12 × 4 = 48 < 50), while T = 5 is the smallest integer that clears the requirement (12 × 5 = 60 ≥ 50). So the model needs a minimum of 5 intermediate reasoning tokens. This is far fewer than the 50 tokens you would need if you (wrongly) assumed each CoT token supplies exactly one unit of serial computation — that assumption ignores that every generated token gets a fresh, full 12-layer pass, not just one added computation step. It is also one more than the 4 tokens you would get by rounding down instead of up — but a partial layer-pass cannot be reused across tokens, so the depth requirement can only be met by rounding up to the next whole token.

ExplanationThe Bradley-Terry pairwise loss used to train a preference model is L = −ln σ(r(y_w) − r(y_l)). Here z = r(y_w) − r(y_l) = 2.3 − 1.1 = 1.2, so σ(1.2) = 1/(1+e^(−1.2)) ≈ 1/(1+0.30119) ≈ 0.76852. Then L = −ln(0.76852) ≈ 0.263 nats. To see how this affects training, rewrite the loss as the softplus of −z: L = ln(1+e^(−z)), so dL/dz = −e^(−z)/(1+e^(−z)) = σ(z) − 1, whose magnitude is 1 − σ(z). At z = 0 (a completely ambiguous pair) this magnitude is at its maximum, 0.5; at z = 1.2 it has already fallen to 1 − 0.76852 ≈ 0.231, and it keeps shrinking toward 0 as the gap widens further. So a large reward gap means the PM already ranks the pair confidently and correctly, and this pair sends a proportionally weaker gradient — the training signal comes disproportionately from pairs the PM is still unsure about, exactly as in ordinary logistic-regression or RLHF reward-model training. This is precisely why CAI's RLAIF stage — training the harmlessness preference model on AI-generated rather than human-generated comparison labels, then optimizing the policy against that PM via RL — inherits the same Bradley-Terry gradient dynamics as standard RLHF once the PM exists: the mechanics don't care whether the comparison labels came from crowdworkers or from a language model applying the constitution. Reversing which response is "preferred" (as if using −ln σ(r(y_l) − r(y_w))) gives a different value, ≈1.463 nats, corresponding to a mislabeled pair, not this one. The gradient does not scale with σ(z) directly — that claim has the shrinking/growing relationship backwards. And the KL penalty against the SL-CAI reference policy belongs to the separate RL fine-tuning objective that keeps the policy close to its starting point; it is not folded into the preference model's own pairwise training loss.

ExplanationThis is a worked instance of the control problem: the objective you can specify and measure (R, the proxy) is not the objective you actually care about (U, the true objective), and an optimizer that only sees R has no reason to respect U. Step 1 — solve the agent's actual optimization. The agent maximizes R(h) = 20 + 8h − h² over h ∈ [0, 10]. dR/dh = 8 − 2h, which is zero at h = 4. Since d²R/dh² = −2 < 0, this is a genuine interior maximum, and h = 4 lies inside the allowed range. So the RL agent, chasing only its training signal, settles on hint level h = 4, where R(4) = 20 + 32 − 16 = 36. Step 2 — solve for the policy that should have been chosen. The true objective is U(h) = 20 + 8h − 2h². dU/dh = 8 − 4h = 0 gives h = 2, and d²U/dh² = −4 < 0 confirms an interior maximum, again inside [0, 10]. The retention-maximizing hint level is therefore h = 2, giving U(2) = 20 + 16 − 8 = 28. Step 3 — measure the misalignment cost. Evaluate the true objective at the policy the agent actually adopted: U(4) = 20 + 32 − 32 = 20. Comparing the two: U(2) − U(4) = 28 − 20 = 8. By driving the measurable proxy to its own maximum (h = 4), the agent leaves 8 points of the true objective (retention) on the table relative to the retention-optimal policy (h = 2). Notice R and U share the same linear term (8h) — hints genuinely help at first — but U's quadratic penalty (−2h²) is twice as steep as R's (−h²), because heavy scaffolding that inflates the immediate score erodes the effortful retrieval practice that long-term retention depends on. The training signal cannot see this steeper long-run cost, so there is no gradient pulling the agent back from h = 4 toward the truly optimal h = 2 — it is doing exactly what it was rewarded to do. This is why reward misspecification, not raw capability, is the central obstacle in the control problem: even a proxy that is positively correlated with the true goal can, once optimized hard, systematically diverge from it (Goodhart's Law in its RL form).

ExplanationWrite both energies as proportional quantities and take the ratio algebraically before plugging in numbers. Neuromorphic (event-driven) energy ∝ N·r·T, since r·T is the expected number of spikes per neuron over the window and there are N neurons. Conventional (dense, synchronous) energy ∝ N·(T/Δt), since every one of the N neurons is evaluated once per discrete step and there are T/Δt steps. Dividing: ratio = [N·(T/Δt)] / [N·r·T] = 1/(r·Δt). Both N and T cancel completely — the population size and the total simulation length are irrelevant to the ratio; only the per-step firing probability r·Δt survives. This quantity is exactly the average probability that a given neuron spikes within one simulation step (a valid approximation whenever r·Δt ≪ 1, the fine-time-resolution regime used for Poisson spike trains), and it is what neuromorphic-hardware papers call the network's "activity" or "sparsity." Substituting r = 20 Hz and Δt = 2 ms = 0.002 s: r·Δt = 20 × 0.002 = 0.04. So the ratio is 1/0.04 = 25 — the conventional accelerator burns 25 times more energy than the event-driven neuromorphic chip on this workload, purely because it pays for every neuron at every clock step whether or not that neuron actually fired, while the neuromorphic chip only pays for the spikes that actually occur. The 500× answer arises from using 1/Δt alone (= 1/0.002 = 500) and forgetting the firing-rate factor entirely — this wrongly implies the energy advantage depends only on simulation time resolution, not on how sparsely the network actually fires; a network that spiked on literally every step at every neuron would still show zero energy advantage, yet 1/Δt alone would still claim 500×. The 40× answer comes from multiplying r·Δt without converting milliseconds to seconds (20 × 2 = 40) and skipping the reciprocal, mixing up two separate mistakes that happen to still produce a "reasonable-looking" number. The 2.5× answer comes from a decimal-conversion slip, treating 2 ms as 0.02 s instead of 0.002 s, understating the true sparsity advantage by exactly a factor of ten. The general lesson generalizes directly: the energy advantage of event-driven neuromorphic hardware over synchronous dense hardware scales as the reciprocal of the network's average per-step firing probability — the sparser (lower-activity) the spiking network, the larger the energy savings, which is precisely why neuromorphic chips target sparse, biologically-realistic firing regimes rather than densely active ones.

ExplanationStart with the pooled rates: total app users = 700 + 100 = 800, of whom 490 + 95 = 585 passed, giving 585/800 = 73.125% ≈ 73.1%. Total non-users = 100 + 700 = 800, of whom 60 + 630 = 690 passed, giving 690/800 = 86.25%. Taken at face value, this roughly 13-point gap looks like the app is associated with worse results. Now compute the rates within each stratum of prior performance. Among weak students, app users pass at 490/700 = 70% against 60/100 = 60% for non-users — a 10-point advantage for app users. Among strong students, app users pass at 95/100 = 95% against 630/700 = 90% for non-users — a 5-point advantage for app users. So in every subgroup defined by prior performance, using the app is linked to a higher pass rate — exactly the opposite of what the pooled figures suggested. The resolution is that prior performance, Z, is a confounder: it affects who uses the app (X) — 700 of 800 weak students used it (87.5%) but only 100 of 800 strong students did (12.5%), since weaker students disproportionately seek out extra help — and it affects the outcome (Y) directly, since strong students pass at a high rate whether or not they use the app. Because the app-user group is composed mostly of weak students (who pass less often for reasons unrelated to the app) while the non-user group is composed mostly of strong students (who pass more often regardless), pooling erases the within-group signal and even reverses its sign. This is the textbook structure of Simpson's Paradox, and the standard remedy in observational causal inference is to condition on the confounder — comparing app users to non-users separately within each performance stratum — rather than trusting the marginal, pooled association. Since app use raises the pass rate in both strata (70% vs 60%, and 95% vs 90%), the causally defensible reading is that the app has a positive effect once prior academic strength is held fixed, and the negative pooled correlation is an artifact of confounding, not evidence against the app. The pooled-sample claim ignores that a bigger denominator does not fix a biased comparison — composition, not sample size, is the problem. The effect-modification claim is contradicted by the data itself, since strong-student app users pass more often (95%) than strong-student non-users (90%), not less. The no-valid-claim position is an overcorrection: once the confounder is identified and both strata show large, consistent samples in the same direction, discarding the analysis entirely ignores the explanation the data already provides.

ExplanationLet x be the number of GPU-hours run per year, held constant across the 3-year horizon, so the GPU logs 3x hours in total. Owning costs the fixed purchase price plus the per-hour operating cost every hour it runs: total 3-year ownership cost = 25,00,000 + 35·(3x). Renting has no fixed cost, only the per-hour rate: total 3-year rental cost = 250·(3x). Setting them equal: 25,00,000 + 105x = 750x 25,00,000 = 645x x = 25,00,000 / 645 ≈ 3,875.97 GPU-hours per year This is the annual usage at which the two options cost exactly the same over 3 years; using the GPU more than this makes buying strictly cheaper, since every extra hour then saves ₹215 (the ₹250 rental rate minus the ₹35 operating cost) against a purchase price that is already sunk. Expressed as a share of the 8,760 hours available in a year: 3,875.97 / 8,760 ≈ 0.4425 → about 44% The key structural insight is that the ₹215-per-hour gap between the rental rate and the ownership operating cost is what pays back the ₹25,00,000 capital outlay — the break-even point is where 3 years of that per-hour saving, at the given utilization, exactly equals the purchase price. Below roughly 44% utilization, the fixed cost of ownership is spread over too few hours to beat renting; above it, owning wins. The distractors reproduce specific, common set-up errors: assuming a longer (5-year) depreciation period than the problem states artificially lowers the break-even utilization; dropping the ₹35-per-hour operating cost from the ownership side understates what owning actually costs and shifts the break-even downward; and measuring utilization against a "business hours" 260-day year rather than a data centre's true 8,760-hour year inflates the percentage, since GPU clusters — unlike factories — run continuously rather than on a five-day working schedule.

ExplanationLet p1 = 250/10000 = 0.025 be the control model's false-positive rate and p2 = 30/2000 = 0.015 be the canary model's rate. Because the null hypothesis assumes both models share one true false-positive rate, the correct standard error uses the pooled estimate p̂ = (250+30)/(10000+2000) = 280/12000 ≈ 0.02333, not each group's separate rate — pooling is what makes this a valid hypothesis test rather than just a confidence interval. The standard error is SE = √(p̂(1-p̂)(1/n1+1/n2)) = √(0.02333 × 0.97667 × (1/10000 + 1/2000)) = √(0.02279 × 0.0006) ≈ √0.0000137 ≈ 0.0037. The z-statistic is z = (p1-p2)/SE = 0.010/0.0037 ≈ 2.70. Since 2.70 exceeds the critical value 1.96, the drop in false positives is statistically significant at 95% confidence — the improvement is very unlikely to be sampling noise, so the team can safely promote the canary model to full production traffic. Using each sample's own proportion instead of the pooled estimate (giving z ≈ 3.19) breaks the null hypothesis's assumption that both groups share one true rate before their data is combined — it happens to point to the same decision here, but it is not the statistically correct test for this hypothesis. Reading 1.96 as the computed statistic confuses the decision threshold with the measured effect: 1.96 is the fixed value from the standard normal distribution the team compares against, not an output of this particular calculation, and it is only a coincidence-prone trap, not the actual z here. Treating the control model's rate as a fixed constant (z ≈ 2.96) ignores that the 10,000-transaction control sample is itself a random draw with its own sampling uncertainty, understating the combined standard error a valid two-sample comparison requires.

ExplanationBecause chat completion APIs — Claude's Messages API, GPT's Chat Completions API, and Gemini's generateContent API — are stateless, the client must resend the full conversation transcript with every call; the model itself remembers nothing between requests. This means input tokens do not stay constant across a conversation — they grow with each turn as more history piles up. For turn k (k = 1 to 10), the input consists of the 300-token system prompt, all (k−1) prior turns already sent back as history (each contributing 40 user + 160 assistant = 200 tokens), plus the current 40-token user message: input_k = 300 + 200(k−1) + 40 = 340 + 200(k−1). This is an arithmetic sequence running from 340 (turn 1) to 340 + 200(9) = 2,140 (turn 10). Summing all ten terms: 10 × (340 + 2,140)/2 = 12,400 input tokens for the whole conversation. Output tokens are simpler: each of the 10 assistant replies is 160 tokens and is billed only once, as output — never resent as input — giving 10 × 160 = 1,600 output tokens total. Cost = (12,400/1,000,000) × ₹250 + (1,600/1,000,000) × ₹1,250 = ₹3.10 + ₹2.00 = ₹5.10. The distractors correspond to real mistakes when estimating API costs: pricing each call as if only the system prompt and that turn's own message were sent, which misses that history compounds turn over turn; swapping which billing rate applies to input versus output tokens; and forgetting that the system prompt itself is part of what gets resent on every call, not just the growing user/assistant history.

ExplanationContribution margin is price minus variable cost, computed separately for each tier because the discount is marginal. In tier 1 (queries 1 through 20,00,000), the margin is ₹5 − ₹1.50 = ₹3.50 per query, so the first 20,00,000 queries generate a maximum contribution of 20,00,000 × ₹3.50 = ₹70,00,000 toward fixed costs. Since fixed costs are ₹80,00,000, tier 1 alone leaves ₹80,00,000 − ₹70,00,000 = ₹10,00,000 of fixed costs still uncovered. In tier 2 (queries beyond 20,00,000), the margin rises to ₹5 − ₹1.00 = ₹4.00 per query. The number of tier-2 queries needed to cover the remaining ₹10,00,000 is ₹10,00,000 ÷ ₹4.00 = 2,50,000 queries. Total breakeven volume is therefore 20,00,000 + 2,50,000 = 22,50,000 queries per month. Treating the discount as retroactive — applying the ₹4.00 margin to every query, including the first 20,00,000 — understates the true breakeven volume to exactly 20,00,000 queries, since it wrongly assumes queries already sold at the higher tier-1 cost also earn the tier-2 margin. Ignoring the discount entirely and using ₹3.50 as the margin for all queries overstates the breakeven volume to about 22,85,714 queries, since it fails to credit the improved margin available once volume crosses the threshold. And computing the tier-2 queries needed as the full ₹80,00,000 divided by ₹4.00 — rather than only the ₹10,00,000 still uncovered after tier 1 — double-counts the fixed-cost coverage already earned in tier 1, inflating the breakeven volume to 40,00,000 queries. This tiered, marginal-discount structure mirrors how real Indian AI startups negotiate committed-use pricing with LLM API providers (OpenAI, Anthropic, Google) as query volume scales: margins improve step-wise, not retroactively, so a founder's unit-economics model must track contribution by tier rather than applying a single blended rate across the whole month's volume.

ExplanationCompute the norms first: |q| = sqrt(4^2 + 3^2 + 0^2) = sqrt(25) = 5, |A| = sqrt(12^2 + 9^2 + 0^2) = sqrt(225) = 15, and |B| = sqrt(16^2 + 12^2 + 15^2) = sqrt(625) = 25. Next compute the dot products: q·A = 4(12) + 3(9) + 0(0) = 75, and q·B = 4(16) + 3(12) + 0(15) = 100. Read as raw dot products, B's score of 100 beats A's score of 75 -- exactly the shortcut your teammate is proposing. But cosine similarity divides each dot product by the product of the two vectors' norms: cos(q,A) = 75/(5·15) = 75/75 = 1.0, and cos(q,B) = 100/(5·25) = 100/125 = 0.8. Once normalized, A is the better match, and the reason is structural: A = 3q, so A points in exactly the same direction as the query, while B's third coordinate (15) pulls it away from q's direction even though it inflates B's overall length to 25. The teammate's raw-dot-product shortcut only ranks correctly when every embedding in the index has been pre-normalized to unit length (as FAISS's IndexFlatIP or a cosine-configured Pinecone index requires) -- skipping normalization across chunks of unequal length silently biases retrieval toward longer or magnitude-heavy chunks regardless of true semantic relevance, which is exactly the bug this calculation exposes.

ExplanationCounting every adjacent symbol pair across all four words, weighted by frequency, gives (w,e) the corpus-wide top count of 8: 6 from the w-e pair inside "newest_" (n-e-w-e-s-t-_) plus 2 from the w-e pair inside "lower_" (l-o-w-e-r-_). Every other pair falls short — (l,o) and (o,w) each sit at 7, (n,e) at 6, and (e,s)/(s,t)/(t,_) at 6 each. So the first merge fuses w+e into "we", turning "lower_" into l-o-we-r-_ and "newest_" into n-e-we-s-t-_; "low_" and "wide_" are untouched since neither contains an adjacent w,e pair. Re-counting pairs on this updated corpus, (l,o) is now the unique maximum at 7 (5 from "low_" plus 2 from "lower_"), ahead of a four-way tie at 6 among (n,e), (e,we), (we,s), and (s,t)/(t,_). So the second merge fuses l+o into "lo". Applying that to "lower_" (currently l-o-we-r-_) gives lo-we-r-_ — four tokens: lo, we, r, _. The single-most-frequent-word idea is a common trap: once BPE training starts, it never looks at whole-word frequency again — only adjacent-symbol-pair frequency summed across the entire corpus decides each merge. That's exactly why "newest_" being the most frequent word in the table doesn't stop "lower_" from receiving a second merge of its own. Suffix pattern-matching (assuming e+r merges because "-er" looks like a familiar English ending) and multi-symbol fusion (merging three symbols w, e, r into one token in a single step) both contradict how BPE actually works: every merge operation combines exactly one adjacent pair of existing symbols into a new symbol, chosen purely by count, with no notion of linguistic suffixes or trigram jumps.

ExplanationStart with the gradient tensor size: 500,000,000 parameters × 4 bytes (FP32) = 2×10⁹ bytes = 2 GB. Ring all-reduce splits the tensor into N equal chunks and runs it in two phases — a reduce-scatter and an all-gather — each taking N−1 steps where every GPU exchanges a chunk of size S/N with a neighbor. Summing both phases, the total data each GPU sends plus receives is 2(N−1)/N × S, NOT 2×S (that would double-count as if the whole tensor moved with no chunking) and NOT 2(N−1)×S (that would assume every exchange carries the full tensor, making cost grow linearly with GPU count — which is exactly why ring all-reduce is preferred over a naive parameter-server scheme). With N = 8 and S = 2 GB: 2(N−1)/N = 2×7/8 = 1.75, so per-GPU traffic = 1.75 × 2 GB = 3.5 GB. Communication time = 3.5 GB ÷ 50 GB/s = 0.07 s = 70 ms. Because compute and communication are explicitly not overlapped here, the total step time is additive: 130 ms (compute) + 70 ms (communication) = 200 ms. The distractors correspond to real failure modes: assuming perfect compute/communication overlap (130 ms) ignores that the problem states no overlap; treating the transfer as one full 2 GB round trip (210 ms) misses that ring all-reduce moves only 1/N-sized chunks per hop; and assuming each of the N−1 hops carries the complete gradient (690 ms) reproduces the linear-in-N communication cost that ring all-reduce was specifically designed to avoid, which is why it scales to large GPU counts far better than a centralized parameter server does.

ExplanationBatch Normalization normalizes each neuron (feature) independently, using statistics computed across the examples in the mini-batch — not across the features within one example. That across-features approach is what Layer Normalization does instead, and confusing the two axes is the single most common error with these methods. For the first neuron, the mini-batch supplies two values: 2 from Example 1 and 10 from Example 2. Batch mean: μ = (2 + 10) / 2 = 6. Batch variance: BatchNorm uses the biased estimator (dividing by N, not N−1), matching how it computes a running population statistic for inference. σ² = [(2−6)² + (10−6)²] / 2 = (16 + 16) / 2 = 16. Standard deviation: σ = √16 = 4. Normalized value for Example 1's first neuron: (x − μ) / σ = (2 − 6) / 4 = −1.0. With γ = 1 and β = 0, this is also the final output: −1.0. The three wrong values trace to real, specific slips. Computing statistics across Example 1's own four features (2, 4, 6, 8) instead of across the batch gives mean 5, variance 5, and (2−5)/√5 ≈ −1.342 — this is the Layer Norm answer for the same tensor entry, not the Batch Norm one. Dividing the squared deviations by N−1 = 1 instead of N = 2 gives variance 32, std ≈ 5.657, and (2−6)/5.657 ≈ −0.71 — the right axis but the wrong (unbiased) variance formula. Dividing by the variance (16) instead of the standard deviation (4) gives (2−6)/16 = −0.25 — a units error, since variance has squared units and cannot be used directly to rescale a deviation. The key structural fact worth remembering: Batch Norm's statistics depend on which other examples happen to sit in the mini-batch, which is exactly why it becomes unreliable at batch size 1 or with variable-length sequences — this is precisely why Transformer and RNN architectures use Layer Norm instead, since it normalizes each example independently of every other example in the batch.