A school-district enrollment analytics team sees rare permit-fraud flags and wants to avoid naïvely duplicating minority rows in GPU memory. Which imbalance strategy is the better first choice?
Select an answer to reveal the explanation.
Short Explanation
Duplicating rare fraud flags is like photocopying the same complaint form until the inbox explodes—it burns memory without new information. Class weights keep one copy of each row but make missing a rare fraud cost more during training.
Full Explanation
A school-district enrollment analytics team with rare permit-fraud flags should prefer class weights when naïve duplication would balloon GPU memory. Class weighting adjusts the loss so minority misses cost more and majority errors cost less, without materializing thousands of copied fraud rows. That keeps one copy of each enrollment record on device while still steering the optimizer toward rare fraud detection—usually the better first choice on already-large civic tables where memory and I/O dominate. Copying each fraud row thousands of times until device memory fills fails by concept: it burns GPU RAM and I/O without adding new information and can stall overnight jobs. Undersampling until only fraud rows remain fails because majority enrollment context disappears and the model never learns what normal looks like in production traffic. Shuffling labels randomly fails by destroying the fraud signal entirely and making the task impossible rather than balanced. Exam caveat: class weights change decision tradeoffs; overly large minority weights can flood staff with false fraud alerts even when recall rises. Operational check: set class weights from inverse frequency or policy cost ratios on the enrollment fraud task, train without row duplication, monitor GPU memory versus an oversampled control, and evaluate minority recall plus false-positive burden on a held-out district extract before changing production thresholds.