EfficientAD in der Praxis: visuelle Anomalieerkennung an MVTec-AD-Flaschen mit Anomalib

Warum nur mit normalen Bildern lernen

Überwachte Klassifikation lernt, eine Menge annotierter Klassen voneinander zu trennen. In der industriellen Inspektion ist es teuer oder unpraktikabel, Beispiele für jeden möglichen Fehler zu sammeln, und ein Werk kann auf Fehler stoßen, die selten sind oder noch nie gesehen wurden.

Visuelle Anomalieerkennung geht einen anderen Weg. Sie lernt, wie normale Produkte aussehen, und markiert dann Bilder oder Bildregionen, die davon abweichen. Ein Modell, das mit normalen Flaschen trainiert wurde, kann zum Beispiel einen gebrochenen Rand oder eine unerwartete Verunreinigung zur Testzeit markieren.

Sie liefert zwei Ausgaben, die unterschiedliche Fragen beantworten.

• Die Erkennung auf Bildebene schätzt, ob ein Bild als Ganzes anomal aussieht.
• Die Lokalisierung auf Pixelebene erzeugt eine Anomalie-Karte, die zeigt, wo ungewöhnliche Regionen liegen können.

Ein Anomalie-Score ist nicht automatisch eine Wahrscheinlichkeit. Er ist eine Zahl dafür, wie ungewöhnlich eine Eingabe erscheint, und ein Entscheidungsschwellenwert macht aus Scores die Vorhersagen „normal“ oder „anomal“.

Wie EfficientAD funktioniert, in einfachen Worten

Veröffentlicht Dieser Abschnitt fasst die Veröffentlichung zusammen: Kilian Batzner, Lars Heckler und Rebecca König, „EfficientAD: Accurate Visual Anomaly Detection at Millisecond-Level Latencies“, WACV 2024, S. 128–138 (arXiv:2303.14535).

Die Methode kombiniert einen effizienten Merkmalsextraktor mit einem Student-Teacher-Ansatz und einem Autoencoder-basierten Zweig, der den breiteren Bildkontext betrachtet. Sie lernt nur aus fehlerfreien Trainingsbildern. Bei der Inferenz vergleicht sie Merkmalsdarstellungen, die verschiedene Teile des Modells erzeugen, und eine Abweichung kann auf eine Anomalie hindeuten.

Es gibt drei Hauptkomponenten.

• Teacher-Netz. Liefert die Ziel-Bildmerkmale. In der Veröffentlichung ist der Teacher ein kompaktes Patch Description Network (PDN), das aus einem größeren vortrainierten Netz destilliert wurde.
• Student-Netz. Lernt, die Merkmale des Teachers auf normalen Trainingsbildern vorherzusagen. Zur Testzeit kann es den Teacher in anomalen Regionen verfehlen.
• Autoencoder-Zweig. Lernt normale Merkmalsmuster und hilft, bestimmte globale oder logische Anomalien zu finden: ungewöhnliche Kombinationen oder Anordnungen, die sich aus einem kleinen lokalen Ausschnitt allein nicht erkennen lassen.

Der Student-Teacher-Vergleich erfasst lokale Abweichungen in Textur oder Struktur. Der Autoencoder-Zweig ergänzt den breiteren Kontext. Die Anomaliesignale werden kalibriert und zu einer räumlichen Anomalie-Karte und einem Score auf Bildebene kombiniert.

Warum Effizienz zählt

Manche Verfahren zur Anomalieerkennung brauchen aufwendige Suchen in gespeicherten Merkmalsvektoren oder rechenintensive Netze. EfficientAD soll die Inferenzkosten mit einer leichtgewichtigen Merkmalsextraktion und einem kompakten Student-Teacher-Modell senken. Damit ist es ein Kandidat für Anwendungen, in denen die Prüfung schnell geschehen muss. Die Autoren werten es auf Datensätzen zur industriellen Anomalieerkennung aus und berichten von Inferenz im Millisekundenbereich auf moderner GPU-Hardware.

Diese Latenz wurde unter den Versuchsbedingungen der Autoren gemessen. Sie überträgt sich nicht automatisch auf jede GPU, CPU, Eingabeauflösung oder jedes Edge-Gerät. Messen Sie daher auf der Hardware, die Sie einsetzen wollen.

Was wir ausgeführt haben

Gemessen Ziel war es, einen praktischen durchgängigen Ablauf zu prüfen: Daten vorbereiten, EfficientAD-S trainieren, Vorhersagen erzeugen, Anomalie-Karten ansehen und Metriken auf Bild- und Pixelebene berechnen. Verwendet wurde die EfficientAD-Implementierung von Anomalib. Es war keine vollständige Reproduktion aller Einstellungen aus der Veröffentlichung.

Umgebung

Die Paketversionen in Colab können sich ändern. Notieren Sie die Versionen, die Sie tatsächlich erhalten, und prüfen Sie die Kompatibilität, bevor Sie versuchen, das Experiment nachzustellen.

Datensatz

Das Experiment verwendete die Kategorie bottle aus einem Hugging-Face-Mirror von MVTec AD. Der ursprüngliche Download-Weg über die Bibliothek lieferte in diesem Durchlauf den HTTP-Fehler 404, deshalb wurde ein Mirror genutzt.

Für das Training wurden nur normale Bilder verwendet. Bilder mit Defekten blieben dem Test vorbehalten, und die Ground-Truth-Masken dienten dazu, die Lokalisierung auszuwerten.

Dies ist eine Teilmenge aus einem Mirror, nicht der vollständige offizielle MVTec-AD-Benchmark der Kategorie „bottle“. Die Ergebnisse müssen als Ergebnisse auf einer Teilmenge angegeben werden und sollten nicht direkt mit veröffentlichten Werten des vollständigen Benchmarks verglichen werden. Prüfen Sie die aktuelle Lizenz und die Nutzungsbedingungen des Datensatzes, bevor Sie ihn weitergeben oder kommerziell nutzen.

Schritt für Schritt in Google Colab

Die folgenden Schritte dokumentieren das Experiment. Download-Adressen und Paketabhängigkeiten können sich ändern. Betrachten Sie deshalb das gespeicherte Notebook als maßgebliche Quelle für die ursprünglichen Code-Zellen und prüfen Sie die Verzeichnisstruktur, bevor Sie etwas erneut ausführen. Die Codeblöcke hier sind die Zellen, die das Tutorial wiedergibt. Für die Schritte 3 und 4 enthält das Tutorial keinen Code, und wir haben keinen ergänzt.

Schritt 1: Ein Colab-Notebook mit GPU anlegen

Öffnen Sie Google Colab, legen Sie ein Notebook an und wählen Sie Runtime → Change runtime type → GPU. Prüfen Sie dann die Laufzeitumgebung.

import torch

print("PyTorch:", torch.__version__)
print("CUDA available:", torch.cuda.is_available())
if torch.cuda.is_available():
    print("GPU:", torch.cuda.get_device_name(0))

Das Experiment lief auf einer NVIDIA Tesla T4.

Schritt 2: Abhängigkeiten installieren und prüfen

Die dokumentierte Umgebung verwendete Anomalib 2.7.0, PyTorch 2.11.0+cu130 und torchvision 0.26.0+cu130. Installieren Sie kompatible Abhängigkeiten in einer frischen Laufzeitumgebung und prüfen Sie dann die Importe. Die in Colab vorinstallierte Kombination aus PyTorch und CUDA kann abweichen. Vermeiden Sie deshalb, inkompatible Binär-Builds zu mischen.

import torch
import torchvision
import anomalib

print("PyTorch:", torch.__version__)
print("Torchvision:", torchvision.__version__)
print("Anomalib:", anomalib.__version__)
print("CUDA available:", torch.cuda.is_available())

Schritt 3: Datensatz herunterladen und prüfen

Das Experiment nutzte huggingface_hub.snapshot_download, um die Kategorie „bottle“ aus einem Hugging-Face-Mirror zu laden. Das entstandene Verzeichnis musste normale Trainingsbilder, Testkategorien und Ground-Truth-Masken in einer Struktur enthalten, die das MVTec-AD-Datenmodul von Anomalib akzeptiert.

Vereinfachte erwartete Struktur:

bottle/
├── train/
│   └── good/
├── test/
│   ├── good/
│   ├── broken_large/
│   ├── broken_small/
│   └── contamination/
└── ground_truth/
    ├── broken_large/
    ├── broken_small/
    └── contamination/

Prüfen Sie nach dem Download die Dateizahlen und das tatsächliche Verzeichnislayout, denn Mirrors können sich ändern. Der ursprüngliche Download-Weg lieferte in diesem Experiment den HTTP-Fehler 404. Verwenden Sie genau die im Notebook festgehaltene Quelle und prüfen Sie deren Lizenz.

Schritt 4: Das Datenmodul konfigurieren

Das MVTec-AD-Datenmodul von Anomalib übernimmt das Laden der Bilder, die Transformationen, das Batching und die Aufteilung in Training und Test. Konfigurieren Sie es für die Kategorie „bottle“ und das Wurzelverzeichnis des heruntergeladenen Datensatzes. Das Experiment verwendete eine Trainings-Batchgröße von 1, eine Auswertungs-Batchgröße von 4 und zwei Data-Loader-Worker.

Die genauen Konstruktorargumente hängen von der installierten Anomalib-Version und vom Pfad im Notebook ab. Verwenden Sie die Zelle für das Datenmodul aus dem gespeicherten Notebook, statt versionsabhängige Argumente zu raten, und sehen Sie sich vor dem Training einen Beispiel-Batch an.

Schritt 5: EfficientAD-S initialisieren

Das Modell wurde über Anomalib initialisiert.

from anomalib.models import EfficientAd

model = EfficientAd(
    model_size="small",
    imagenet_dir="/content/datasets/imagenette",
)

Das Argument imagenet_dir verweist auf Zusatzdaten, die diese Implementierung nutzt. Bei der Einrichtung lud das Experiment vortrainierte Teacher-Gewichte und Imagenette-Daten herunter, berechnete Statistiken der Teacher-Merkmale und Quantile für die Validierung und ging dann zum Training über. Diese Details gelten für die verwendete Implementierung und Version.

Schritt 6: Das Modell trainieren

Die Engine von Anomalib koordiniert Training, Validierung, Checkpoints und Vorhersage. Das Experiment verwendete eine GPU, höchstens 10 Epochen und /content/results/efficientad_bottle als Wurzelverzeichnis für die Ergebnisse.

from anomalib.engine import Engine

engine = Engine(
    max_epochs=10,
    accelerator="gpu",
    devices=1,
    default_root_dir="/content/results/efficientad_bottle",
)

engine.fit(model=model, datamodule=datamodule)

Hier ist datamodule das in Schritt 4 konfigurierte Datenmodul. Verwenden Sie die Variablennamen und Argumente aus dem gespeicherten Notebook. Das Training endete nach den angeforderten 10 Epochen.

Schritt 7: Den Checkpoint finden und sichern

Der Checkpoint wurde hier gespeichert:

/content/results/efficientad_bottle/EfficientAd/MVTecAD/bottle/v1/weights/lightning/model.ckpt

Er war etwa 73,4 MB groß. Der lokale Speicher von Colab ist flüchtig. Kopieren Sie den Checkpoint und wichtige Ergebnisse deshalb in einen dauerhaften Speicher, bevor Sie die Verbindung trennen oder die Laufzeitumgebung zurücksetzen.

Schritt 8: Inferenz ausführen

Die Vorhersagen wurden mit dem trainierten Checkpoint erzeugt.

predictions = engine.predict(
    model=model,
    datamodule=datamodule,
    ckpt_path=checkpoint_path,
)

checkpoint_path zeigt auf die gespeicherte Datei model.ckpt. Der Aufruf lieferte 21 Batches, die bei einer Auswertungs-Batchgröße von 4 die 83 Testbilder abdeckten.

Die Vorhersage-Batches enthielten unter anderem diese Felder:

• image_path: Speicherort des Quellbilds
• pred_score: Anomalie-Score auf Bildebene
• pred_label: vorhergesagtes Label, normal oder anomal
• anomaly_map: räumliche Anomalie-Scores
• gt_label und gt_mask: Ground-Truth-Labels und -Masken, soweit vorhanden

Die Anomalie-Karte des ersten Batches hatte die Form 4 × 256 × 256. Eine Region mit hohem Score kennzeichnet eine möglicherweise ungewöhnliche Region, keinen bestätigten Defekt.

Schritt 9: Anomalie-Karten ansehen

Anomalie-Karten zeigen, wo das Modell ungewöhnliche Muster vermutet. Vergleichen Sie jede Karte mit dem Originalbild und der Ground-Truth-Maske.

In den ersten vier Beispielen der Kategorie broken_large reagierte das Modell um Teile der beschädigten Flaschenränder, aber die vorhergesagten Regionen deckten nicht jeden Ground-Truth-Defekt exakt ab. Ein Bild kann richtig klassifiziert werden, auch wenn die Lokalisierung unvollkommen ist.

Sehen Sie sich falsch positive und falsch negative Fälle, kleine Defekte und normale Bilder bei unterschiedlicher Beleuchtung und Position an, nicht nur einige gelungene Beispiele.

Schritt 10: Metriken berechnen

Das Experiment berechnete Genauigkeit auf Bildebene, Balanced Accuracy, AUROC auf Bildebene, AUROC auf Pixelebene und AU-PRO.

• Genauigkeit (Accuracy): der Anteil der Bilder, die beim gewählten Schwellenwert richtig klassifiziert werden.
• Balanced Accuracy: der Mittelwert aus Sensitivität (Anteil der erkannten fehlerhaften Bilder) und Spezifität (Anteil der korrekt akzeptierten normalen Bilder).
• AUROC: wie gut die Scores anomale Beispiele über alle Schwellenwerte hinweg vor normalen einordnen. Der AUROC auf Bildebene nutzt einen Score pro Bild. Der AUROC auf Pixelebene nutzt die Scores der Anomalie-Karte und die Pixel-Labels.
• AU-PRO: die Überlappung zwischen vorhergesagten anomalen Regionen und Ground-Truth-Defektregionen, wobei falsch positive Pixel berücksichtigt werden. Hier wurde eine Falsch-positiv-Rate-Grenze von 0,30 verwendet.

Anomalie-Scores sind keine kalibrierten Wahrscheinlichkeiten. Die Genauigkeit hängt vom Schwellenwert ab, den die Modellkonfiguration wählt, während der AUROC die Rangfolge über alle Schwellenwerte hinweg bewertet.

Ergebnisse

Gemessen Alle Zahlen in diesem Abschnitt stammen aus einem Durchlauf auf der oben beschriebenen Teilmenge mit 83 Bildern. Es sind Ergebnisse auf einer Teilmenge, keine offiziellen Benchmark-Ergebnisse.

Gesamtmetriken

Ergebnisse nach Kategorie

Die mittleren Anomalie-Scores sind beschreibende Werte, keine Wahrscheinlichkeiten.

Konfusionsmatrix

Die Zeilen sind die tatsächlichen Klassen, die Spalten die vorhergesagten. Die Reihenfolge der Klassen ist normal, anomal.

Unter den 20 normalen Bildern gab es einen falsch positiven Fall, unter den 63 fehlerhaften Bildern einen falsch negativen.

Was die Ergebnisse zeigen und was nicht

Auf dieser kleinen Teilmenge ordnete das Modell normale und fehlerhafte Bilder gut und lieferte brauchbare Lokalisierungssignale. Die Anomalie-Karten zeichneten nicht jeden Defekt perfekt nach. Deshalb müssen Erkennung auf Bildebene und Lokalisierung auf Pixelebene getrennt bewertet werden.

Diese Ergebnisse belegen keine Produktionsreife. Die Testteilmenge ist klein und bildet die Bedingungen in einer Fertigung möglicherweise nicht ab. Bevor jemand Aussagen für den Betrieb trifft, braucht es repräsentativere Daten, eine wiederholbare Auswertung, eine Analyse der Schwellenwerte, eine Analyse der Fehlerfälle und Tests unter realistischer Beleuchtung sowie realistischen Kamera- und Produktvariationen.

Von Flaschen zu Verpackungen

Das Flaschenexperiment zeigt einen Ablauf, der sich auf die Verpackungsprüfung übertragen ließe. Die Leistung bei Verpackungen belegt es nicht. Eine nächste Phase könnte so aussehen:

• Die Verpackungsart und die relevanten Fehler festlegen, etwa beschädigte Kartons, eingerissene Beutel, sichtbare Siegelfehler oder beschädigte Etiketten.
• Repräsentative Bilder mit dem vorgesehenen Kamerawinkel, der vorgesehenen Beleuchtung, Entfernung und den Produktionsbedingungen sammeln.
• Mit normalen Beispielen trainieren und fehlerhafte Beispiele für Validierung und Test zurückhalten.
• Sowohl die Erkennung auf Bildebene als auch die Lokalisierung von Defekten bewerten und Fehlalarme sowie übersehene Fehler untersuchen.
• Entscheidungsschwellenwerte anhand der Kosten übersehener Fehler im Vergleich zu den Kosten unnötiger Aussortierungen wählen.
• Auf der vorgesehenen Edge-Hardware testen und Latenz, Durchsatz, Speicherverbrauch und Konsistenz der Vorhersagen messen.

EfficientAD kann sichtbare Abweichungen markieren. Fehler, die im Bild nicht zu sehen sind, kann es nicht garantiert erkennen. Für die exakte Prüfung von Text, das Aufspüren verdeckter Lecks oder die Prüfung innenliegender Siegel können andere Prüfverfahren nötig sein.

Der Weg zum Edge-Einsatz

Das vorliegende Experiment lief auf einer Tesla T4 in Colab. Ein Einsatz auf einem Raspberry Pi oder einem NVIDIA-Jetson-Gerät wurde nicht getestet. Der vorgeschlagene Plan lautet:

1. Den vorhandenen trainierten Checkpoint nutzen, um den Export zu untersuchen, statt sofort mit Verpackungsdaten neu zu trainieren.
2. Die Exportoptionen der installierten Anomalib-Version prüfen und den ONNX-Export testen, sofern er unterstützt wird.
3. Prüfen, dass die exportierte Inferenz Anomalie-Scores und Karten liefert, die hinreichend konsistent mit dem ursprünglichen Modell sind.
4. Auf dem tatsächlichen Zielgerät Latenz im Warm-up und im stationären Betrieb, Durchsatz, Speicherverbrauch sowie CPU- und GPU-Auslastung messen.
5. Bei kompatibler NVIDIA-Hardware die Beschleunigung mit TensorRT untersuchen und nach der Optimierung die Konsistenz der Ausgaben prüfen.
6. Die Leistungs- und Erkennungstests mit der vorgesehenen Bildauflösung und Prüfrate wiederholen.

Ein erfolgreicher Export in Colab beweist nicht, dass das Modell auf Edge-Hardware die geforderte Geschwindigkeit erreicht. Das Zielgerät und die Betriebsbedingungen müssen bekannt sein, bevor jemand diese Aussage trifft.

Einschränkungen

• Das Experiment nutzt eine Teilmenge der MVTec-AD-Kategorie „bottle“, nicht den vollständigen offiziellen Benchmark.
• Der Testsatz hat nur 83 Bilder, was die statistische Aussagekraft begrenzt.
• Das Training war auf 10 angeforderte Epochen begrenzt. Es war eine Prüfung der Pipeline, keine Studie zur Hyperparameter-Wahl.
• Ausgewertet wurden nur ein Durchlauf und eine kleine Zahl von Visualisierungen.
• Es wurde kein Edge-Gerät vermessen.
• Gute Leistung bei Flaschen garantiert keine gute Leistung bei anderen Produkten, Verpackungsmaterialien, Beleuchtungsbedingungen oder Fehlerarten.

Diese Einschränkungen sollten die Ergebnisse immer begleiten, wenn sie veröffentlicht werden.

Wo das hinführt

Das Tutorial hat den Kernablauf durchlaufen: Datenvorbereitung, Training, Checkpoints, Inferenz, Sichtung der Anomalie-Karten und Berechnung der Metriken. Weil der Datensatz begrenzt war und die Lokalisierung unvollkommen blieb, sind die Ergebnisse als vorläufig zu behandeln.

Der nächste Schritt ist, Fehlerfälle zu untersuchen, an einem repräsentativeren Datensatz zu validieren und Export und Inferenz auf der tatsächlichen Edge-Hardware zu testen. Erst dann lässt sich der Ansatz für die Verpackungsprüfung unter realen Bedingungen bewerten.

Quellen

• Batzner, K., Heckler, L., & König, R. (2024). EfficientAD: Accurate Visual Anomaly Detection at Millisecond-Level Latencies. Proceedings of the IEEE/CVF Winter Conference on Applications of Computer Vision (WACV), 128–138. arXiv:2303.14535
• Open-Access-Seite der Veröffentlichung (CVF)
• Anomalib: Implementierung und Dokumentation

@article{beyondpixels_efficientad_bottle_anomaly_detection,
  title   = {EfficientAD in der Praxis: visuelle Anomalieerkennung an MVTec-AD-Flaschen mit Anomalib},
  author  = {Pawan},
  journal = {Beyond Pixels},
  year    = {2026},
  url     = {https://beyondpixels.dev/de/blog/efficientad-bottle-anomaly-detection/}
}