Reconstruction-Based vs. Memory-Bank Anomaly Detection for a New SKU
You're onboarding two new SKUs onto edge boxes that already host several other SKUs' models:
- SKU A is a textured fabric panel where defects are subtle, diffuse weave irregularities spread across large regions, not sharply-localized marks. The edge box for this line is a higher-spec unit with generous RAM headroom.
- SKU B is a small metal bracket with sharp, highly localized defects (a crack, a missing hole). The edge box for this line is already close to its memory ceiling from the other SKUs it hosts, and adding one more large PatchCore-style memory bank would exceed it.
- Which approach-ladder rung (reconstruction-based / GAN, or feature-memory-bank) would you argue for on each SKU, and why?
- For SKU B specifically, name the concrete architectural reason a memory-bank method's footprint grows in a way a trained generator's doesn't, and what lever (from the case) you'd pull before abandoning the memory-bank approach entirely.
- If you picked the reconstruction rung for either SKU, which of AnoGAN or f-AnoGAN would you deploy, and why does the other one fail this line's constraints outright?
1. Rung choice per SKU: SKU A's defect signature — diffuse, texture-level irregularity spread over a region rather than a sharp localized mark — plays to reconstruction-based detection's strength: a generator that has learned the normal weave's texture statistics will reconstruct a diffuse texture shift poorly across a broad area, giving a strong, naturally smooth residual signal, and the higher-spec edge box removes the main practical objection (training/hosting cost) to the generative rung. SKU B's defect signature — sharp, highly localized (a crack, a missing hole) — is close to the textbook case feature-memory-bank methods are validated on (MVTec-AD's object categories skew toward exactly this kind of localized defect), and a memory-bank approach would normally be the first choice here on accuracy and operational-simplicity grounds alone — except the memory constraint on this specific edge box is a real, deployment-level objection that has to be resolved before defaulting to it.
2. The memory-footprint issue and the lever to pull: A PatchCore-style memory bank's size scales with how much normal-image diversity it has to represent — every additional golden image (up to the coreset-subsampled cap) potentially adds distinct patch embeddings the bank has to store to cover normal variation, so the bank's memory footprint grows with the SKU's captured normal-variation range, not with a fixed parameter count. A trained reconstruction model's footprint, by contrast, is just its decoder's fixed parameter count regardless of how many normal images it was trained on. Before abandoning the memory-bank approach for SKU B, the lever to pull is more aggressive coreset subsampling — accepting a smaller, more aggressively deduplicated memory bank at some cost to how finely it represents rare normal-variation edge cases — and re-validating that the smaller bank still clears the pixel-PRO/AUROC bar on the synthetic-defect suite before concluding the memory-bank rung genuinely doesn't fit this box and falling back to a reconstruction model instead.
3. AnoGAN vs. f-AnoGAN:
f-AnoGAN, not AnoGAN, for either SKU where the reconstruction rung is
chosen. AnoGAN's anomaly scoring requires an iterative per-image
latent-vector search at inference time to find the z that best
reconstructs the query image — this is fundamentally incompatible
with the line's ~200–500 ms cycle-time budget, regardless of how
accurate the resulting score would be given unlimited time. f-AnoGAN
replaces that search with a separately trained encoder that maps an
image directly into latent space in a single forward pass, which is
the only version of reconstruction-based scoring that fits inside a
hard, per-part real-time budget — the same "single forward pass, not
an iterative process" property that makes GANs the default choice for
any latency-bound product in this track.
Share this question