LG Aimers 5th: Product Defect Detection with Stacking and SMOTE-ENN

This summer I joined LG Aimers 5th, Product Defect Detection. The crux was extreme class imbalance: defects were under 1% of all rows. This post records the technical choices that got me to the top 5.5% among ~1,400 participants.

Problem definition and approach

The metric was F1. Predicting everything as “normal” still yields ~99% accuracy, the classic accuracy trap. The goal was to lift minority-class detection without drowning in false positives. I structured the work as:

• EDA and preprocessing
• Handling imbalance (sampling)
• Training individual models
• Boosting performance with an ensemble

Core techniques

Why SMOTE-ENN?

Plain oversampling risks overfitting; undersampling wastes information. SMOTE-ENN is a hybrid that mitigates both.

• SMOTE: Learns minority patterns and synthesizes new points so the model sees more “defect-like” examples.
• ENN: Strips noisy majority points near the decision boundary so the boundary is cleaner.

Ablation: Versus SMOTE alone, SMOTE-ENN lifted Precision by about 8 percentage points. Cutting boundary noise was key to fewer false positives.

That balance helped both precision and recall, the two halves of F1.

Stacking: smarter than a simple average

I built a stacking ensemble. Unlike averaging, stacking trains a meta-model to learn which base model to trust.

• Base models (level 1): LGBM, XGBoost, CatBoost: different growth rules and categorical handling mean genuinely different views. That diversity is the point.
• Meta-model (level 2): Takes base predictions and outputs the final score, often a simple logistic regression to limit overfitting.

Data distribution and resampling

• Original: ~99k normal / ~1k anomaly (≈1.0% anomaly rate)
• After SMOTE-ENN: ~98.5k normal / ~9.98k anomaly
• Validation: Stratified K-Fold (k=5); the meta-model trains on out-of-fold base predictions to avoid leakage.

Results and reflection

I finished in the top 5.5% of ~1,400 teams. End-to-end, from heavy preprocessing through tuning, I compressed a lot of real ML practice into one sprint.

I missed the finals by a hair, and that stings more. In hindsight three gaps were obvious:

• Thin feature engineering: I leaned on given columns and barely engineered new signals.
• Weak experiment hygiene: I tried many hyperparameter combos but did not log runs systematically, so retracing the best mix was inefficient.
• Bad time allocation: I spent too long in early EDA and ran short on tuning and ensemble polish at the end.

What I would do next time

Looking back, skipping feature work was the biggest regret. On process and measurement data, ratios between variables, binned distributions, and similar domain features would almost certainly have helped. Next time I will budget EDA and feature creation separately from day one.

I also scribbled scores in Notion without a real tracker and sometimes re-ran the same experiment twice. I learned the hard way that MLflow (or any tracker) should be there from the first commit.

Closing

Missing finals by a sliver hurts, but the skill gap was real, especially on feature depth. Now that the weak spots are explicit, the next competition feels less like roulette.