Anomalib neden varsayılanımız
Intel'in Anomalib'i son iki yılda denetimsiz anomali tespiti için de facto çerçeve hâline geldi. Yeni projelerde varsayılan olarak seçiyoruz çünkü:- Yayınlanan mimarilerin çoğu (PatchCore, EfficientAD, FastFlow, PaDiM, ReverseDistillation) gerçeklenmiş ve doğrulanmış.
- PyTorch Lightning tabanı, eğitim döngülerimizin, callback'lerimizin ve loglamamızın özel kod olmadığı anlamına gelir.
- OpenVINO export tek bayrak — Intel CPU hedefi olduğunda anlamlı.
- Veri seti soyutlamaları MVTec tarzı klasör yapılarını kutudan ele alır.
Yetersiz kaldığı yer (deneyimimizle)
Anomalib akademik benchmark iş akışı etrafında inşa edilmiş. Üretim farklı görünür.Özel veri seti şekilleri. Veriniz temiz train/good + test/good + test/anomaly klasör ayrımı değilse, özel bir Datamodule yazıyorsunuzdur. Bunlardan küçük bir kütüphanemiz var: süregelen üretim çekimleri için, açıklamalı red logları için ve küratör geçişi gerektiren gürültülü "iyi" setleri için.
Online öğrenme / artımlı güncelleme. Anomalib veri seti değiştiğinde sıfırdan yeniden eğitim bekler. Memory-bank modeli için bu çoğunlukla iyi — banka yeniden inşası hızlıdır. Damıtma modelleri için ya gece yeniden eğitiyor ya da drift'i kabul ediyorsunuz.
Drift tespiti. Çerçevenin kapsamında yok. Gömülü çıkarıcının özellik dağılımını izleyen ve kalibrasyon temelinden KL ayrışması bir eşiği geçtiğinde uyarı veren ayrı bir servis ekliyoruz.
Operatör odaklı inference sonuçları. Anomali haritaları araştırma için görselleştirme amaçlı son işlemden geçirilir. Üretimde operatör, HMI'sine boyutlanmış overlay PNG'leri ve EXIF metadata'sında anomali skoru ister. Bu kullanıcı kodudur.
Üstüne yazdığımız kod şekli
- Diskten yerine hat görüntü veritabanımızdan (PostgreSQL + S3) çeken dataset adaptörü.
- Threshold servisi: kamera başına, vardiya başına eşik tutar, küçük bir operatör geri besleme döngüsünden online recalibration ile.
- Drift watcher: 15 dakikada bir çalışır, son embedding'leri hash'ler, temele karşı karşılaştırır.
- Sonuç yayıncısı: anomali skoru + heatmap'i PLC için MQTT'ye ve audit izi için ilişkisel tabloya yazar.
- Yeniden eğitim pipeline'ı: planlı sıklıkla veya drift uyarısıyla tetiklenir.
Değerlendirip seçmediğimiz alternatifler
- MVTec'in ticari çerçevesi — güçlü ama kendi yığınına kilitli. Müşteri zaten her yerde MVTec çalıştırıyorsa iyi.
- Özel PyTorch — cazibe gerçek ama iki hücreden fazlasını dağıttığınızda bakım maliyeti acımasız.
- ADBench — tablo anomali verisinde benchmark için faydalı, görüntü çalışmalarıyla ilgisi yok.
Bir görüş
Anomali çerçevesinin "çalışıp çalışmadığını" belirleyen şey model implementasyonları değil — veri seti soyutlamasının veri yaşam döngünüze uyup uymadığıdır. Model kodundan çok veri yükleme koduna kat be kat daha fazla zaman harcadık.Ne kullanıyorsunuz? Ölçekte özel yığın çalıştıran var mı, merak ediyoruz.
Why Anomalib is our default
Intel's Anomalib has, over the last two years, become the de-facto framework for unsupervised anomaly detection. We default to it on new projects because:- Most published architectures (PatchCore, EfficientAD, FastFlow, PaDiM, ReverseDistillation) are implemented and validated.
- The PyTorch Lightning base means our training loops, callbacks, and logging are not custom code.
- OpenVINO export is a single flag — meaningful when the deployment target is Intel CPU.
- The dataset abstractions handle MVTec-style folder structures out of the box.
Where it falls short (in our experience)
Anomalib is built around the academic benchmark workflow. Production looks different.Custom dataset shapes. If your data isn't a clean train/good + test/good + test/anomaly folder split, you're writing a custom Datamodule. We have a small library of these for: rolling production captures, annotated rejection logs, and noisy "good" sets that require curation passes.
Online learning / incremental updates. Anomalib expects you to retrain from scratch when the dataset changes. For a memory-bank model, this is mostly fine — bank rebuild is fast. For distillation models, you're either retraining nightly or accepting drift.
Drift detection. Not in scope for the framework. We bolt on a separate service that watches the feature distribution from the embedded extractor and alerts when KL divergence from the calibration baseline crosses a threshold.
Operator-facing inference results. Anomaly maps are post-processed for visualization in research. In production, the operator wants overlay PNGs sized for their HMI, with the anomaly score in the EXIF metadata. That's user code.
The shape of code we end up writing on top
- Dataset adapter that pulls from our line-image database (PostgreSQL + S3) instead of disk.
- Threshold service: maintains threshold per camera, per shift, with online recalibration from a small operator feedback loop.
- Drift watcher: runs on a 15-minute cadence, hashes recent embeddings, compares to baseline.
- Result publisher: writes anomaly score + heatmap to MQTT for the PLC and to a relational table for the audit trail.
- Retrain pipeline: triggers on either a scheduled cadence or a drift alert.
Alternatives we evaluated and didn't pick
- MVTec's commercial framework — strong but locked into their stack. Fine if the customer already runs MVTec everywhere.
- Custom PyTorch — the temptation is real but the maintenance cost is brutal once you have more than two cells deployed.
- ADBench — useful for benchmarking on tabular anomaly data, not relevant for image work.
One opinion
The thing that determines whether an anomaly framework "works" is not the model implementations — it's whether the dataset abstraction matches your data lifecycle. We've burned more time on data-loading code than on model code, by an order of magnitude.What are you using? Curious about anyone running a custom stack at scale.
