Data Analysis and Visualization

A practitioner fits a StandardScaler on the training split, transforms the training data, and then needs to prepare the held-out test split for evaluation. Which action correctly preserves the integrity of the evaluation?

• ARefit a fresh StandardScaler on the test split and transform the test data with those new test-derived statistics.
• BFit one StandardScaler on the combined training and test data and apply it to both splits together.
• CSkip scaling the test split because the model has already learned the appropriate weights from scaled training data.
• DReuse the scaler already fitted on the training split to transform the test data with the training-derived statistics.check_circle Correct

Why A is wrong: Refitting on the test split is tempting because it scales the test data to a clean mean and variance, but it lets test statistics influence preprocessing, producing inconsistent transforms and an unrealistic evaluation.

Why B is wrong: Combining both splits before fitting feels efficient, but it leaks information from the test set into preprocessing, inflating measured performance and breaking the separation the test split exists to guarantee.

Why C is wrong: Leaving the test data unscaled seems harmless since the model is already trained, but the model expects scaled inputs; feeding raw-magnitude test features produces a train-test mismatch and degraded predictions.

Why D is correct: The scaler must learn its mean and standard deviation only from training data and then apply those fixed statistics to the test data, so the evaluation reflects how the model will see genuinely unseen inputs at deployment.

A data scientist loads a 50 GB CSV into a cuDF DataFrame on a single GPU that has only 16 GB of VRAM. After the load step fails with an out-of-memory error, a colleague suggests wrapping the workflow with dask-cuDF instead. Which of the following best explains why dask-cuDF resolves this limitation?

• Adask-cuDF compresses the CSV on disk before loading, reducing the in-memory footprint to a fraction of the original file size so the data fits within a single GPU's VRAM.
• Bdask-cuDF offloads the overflow portion of the DataFrame to CPU RAM using unified memory, transparently extending the effective VRAM capacity without any partitioning or multi-GPU coordination.
• Cdask-cuDF converts the cuDF DataFrame into a cuPy array internally, which uses a more memory-efficient storage format that can hold 50 GB of tabular data within 16 GB of VRAM.
• Ddask-cuDF splits the dataset into partitions that are each processed by a cuDF DataFrame, enabling out-of-core and multi-GPU execution so the full dataset need not reside in one GPU's memory at once.check_circle Correct

Why A is wrong: Tempting because compression does reduce data size, but dask-cuDF does not apply compression to the source file. It partitions the data across multiple GPUs or processes data in chunks, not by compressing the input.

Why B is wrong: Tempting because CUDA unified memory does allow CPU-GPU overflow in some configurations, but that is a low-level CUDA feature, not what dask-cuDF provides. dask-cuDF works through partitioned, distributed execution across multiple GPUs or workers.

Why C is wrong: Tempting because cuPy and cuDF both operate on GPU memory, but cuPy arrays are not more memory-efficient for tabular data. dask-cuDF does not convert DataFrames to cuPy arrays to solve memory limits; it partitions the workload across workers.

Why D is correct: Correct. Dask orchestrates lazy, partitioned execution; each partition is a cuDF DataFrame handled by one GPU. This out-of-core scaling is the primary motivation for using dask-cuDF when a dataset exceeds single-GPU VRAM.

A team's GPU pipeline loads a CSV into pandas first, cleans it, then calls cudf.DataFrame.from_pandas to move it onto the GPU for the heavy aggregation work. The cleaning and aggregation are both fast, but end-to-end the pipeline is barely quicker than an all-CPU version. Profiling attributes most of the wall-clock time to the from_pandas call and the initial CSV read. What is the most effective redesign to capture the GPU benefit?

• AKeep the pandas read but call from_pandas inside a loop over smaller row chunks so each transfer is smaller and the copies overlap with parsing.
• BConvert the cleaned pandas frame to a NumPy array first and pass that to cudf.DataFrame, since array transfers are faster than DataFrame transfers.
• CPin the host DataFrame in page-locked memory before from_pandas so the transfer reaches full PCIe bandwidth and the copy time disappears.
• DRead the CSV directly with cudf.read_csv so parsing and the resulting frame live on the GPU, removing the separate host parse and the host-to-device copy.check_circle Correct

Why A is wrong: Tempting because chunking can pipeline some work, but it still pays the full pandas parse cost and the same total bytes transferred over PCIe; splitting the copy does not remove the host parse that dominates the profile.

Why B is wrong: Tempting because raw arrays sound lighter, but the conversion still copies the same data to the device and loses column dtypes and labels; it does not avoid the host CSV parse, which is the larger cost here.

Why C is wrong: Tempting because pinned memory genuinely speeds host-to-device copies, but it only shrinks the transfer portion and does nothing for the slow pandas CSV parse, so a large share of the wall-clock time remains.

Why D is correct: Correct: reading straight into cuDF parses on the GPU and avoids both the slow pandas CSV parse and the explicit from_pandas host-to-device transfer, eliminating the two dominant costs the profile identified.

A team builds a classifier that tags support emails with any number of applicable labels at once, such as billing, technical, and urgent, where a single email can carry several of these simultaneously. They add a linear head on top of a transformer encoder. Which output activation and loss combination correctly models this task?

• AA sigmoid applied independently to each label logit with binary cross-entropy loss, thresholding each label separatelycheck_circle Correct
• BA softmax over the label set with categorical cross-entropy loss, taking the single highest-probability label as the prediction
• CA softmax over the label set with binary cross-entropy loss, mixing the activation and the loss to allow multiple labels
• DA linear output with mean squared error loss, regressing each label towards zero or one and rounding the values at inference

Why A is correct: Multi-label classification treats each label as an independent binary decision, so a per-label sigmoid with binary cross-entropy lets several labels be active at once and each label is thresholded on its own probability, which matches an email carrying multiple labels.

Why B is wrong: Softmax with categorical cross-entropy is the right choice for single-label classification, which makes it tempting, but softmax forces the probabilities to sum to one and so cannot express several independent labels being true simultaneously.

Why C is wrong: This pairing looks like a compromise that allows multiple labels, but a softmax still couples the outputs into one normalised distribution while binary cross-entropy expects independent per-label probabilities, so the activation and loss are mismatched.

Why D is wrong: Treating the labels as a regression target seems to give independent outputs, but mean squared error is poorly suited to probabilistic classification, converges more slowly, and is not the conventional choice for a multi-label head.

A medical NER system is evaluated on held-out clinical notes. The team observes high token-level accuracy but poor performance in downstream information extraction. Which evaluation metric would best reveal the root cause?

• AToken-level micro-averaged F1, which weights each token equally regardless of entity membership
• BEntity-level F1 (span-level precision and recall), where a prediction counts as correct only when both the span boundaries and entity type match the gold annotationcheck_circle Correct
• CPer-class precision computed separately for each BIO tag, averaged across B- and I- tag types
• DMatthews Correlation Coefficient computed over the full token label distribution including O tags

Why A is wrong: Token accuracy and token-level F1 are both inflated by the large proportion of O-tagged tokens in clinical text. They can appear strong even when the model misses entire entity spans, which is exactly the disconnect the team is seeing.

Why B is correct: Entity-level F1 scores a prediction as correct only if every token in the predicted span matches the gold span exactly, including boundaries and type. This directly measures whether complete, correctly bounded entities are recovered, which is what information extraction pipelines consume. A model with high token accuracy can still score low on entity F1 by consistently getting span endpoints wrong.

Why C is wrong: Computing precision per BIO tag variant (B-DRUG, I-DRUG, B-CONDITION, etc.) is overly granular and still does not reflect whether the full entity span was recovered correctly. It is tempting because it goes beyond flat accuracy, but entity-level span matching is what downstream extraction requires.

Why D is wrong: MCC is a useful single-number metric for binary or multi-class token problems, but including the dominant O class masks span-level errors. It does not address whether full entity spans are correctly recovered, so it would not diagnose the disconnect between token accuracy and extraction quality.