KI in der Praxis: Fehlerhafte Bauteile mit AutoML in der Google Cloud identifizieren

Noch vor kurzer Zeit war der Einsatz von künstlicher Intelligenz (KI) nur mit großem Aufwand und Konstruktion eigener neuronaler Netze möglich. Heute ist die Einstiegshürde in die Welt der KI durch Cloud-Computing-Dienste stark gesunken. So kann man sofort und ohne großes Investment in KI-Forschung aktuelle KI-Technologie zur (Teil-)Automatisierung der Qualitätskontrolle von Bauteilen einsetzen.

Warum es durch die aktuellen Entwicklungen in Cloud-Computing-Diensten für kleine und mittelständischen Unternehmen spannend sein kann, sich mit KI zu beschäftigen, haben wir bereits im Blogpost KI für KMU: (Teil-)Automatisierung der Qualitätskontrolle von Bauteilen beschrieben.

In diesem Artikel zeigen wir, wie ein solches Vorhaben exemplarisch auf der Google Cloud Platform (GCP) umgesetzt werden kann. Dazu trainieren wir mithilfe von AutoML ein Modell und integrieren es mittels Cloud Functions und App Engine perspektivisch in einen Prozess, bei dem manuelle Korrekturen in der Qualitätskontrolle möglich sind.

Der zugehörige Code zu diesem Projekt befindet sich im Repository gcp-automated-quality-inspection .

Architektur des KI-Systems

Die folgende Abbildung zeigt eine Beispielarchitektur auf GCP zur schrittweisen Automatisierung der Qualitätskontrolle von Bauteilen.

Um ein passendes Modell zu trainieren, verwenden wir den Machine-Learning-Service AutoML. Hier ist es möglich, ein State-of-the-Art-KI-Modell zur Bildklassifizierung auf einem eigenen Datensatz zu trainieren. Außerdem können die so trainierten Modelle direkt über den Service als Rest-Endpoint zur Verfügung gestellt werden.

Für die Integration des Modells werden Bilder von Bauteilen in einen Google Cloud Storage (GCS) Bucket abgelegt. Der Upload eines Bildes triggert eine Cloud Function, welche den Endpoint des Modells aufruft und so das Bild klassifiziert. Das Ergebnis der Vorhersage wird dann zur weiteren Verarbeitung auf ein Pub/Sub Topic geschrieben.

Dies triggert eine zweite Cloud Function, welche die Verarbeitungslogik enthält, um die Bilder anhand der Klassifikation und der zugehörigen Konfidenz zu sortieren. Vorhersagen, deren Konfidenz unter einem gewählten Schwellwert liegen, werden als „unsicher“ bezeichnet. Diese Vorhersagen müssen durch Facharbeiter*innen nachbearbeitet werden. Hierfür wurde exemplarisch eine Anwendung geschrieben, über die diese Überprüfung umgesetzt werden kann.

Um alle Komponenten dieses KI-Systems zum Laufen zu bringen, sind die folgenden drei Schritte notwendig:

1. Vorbereitung, Training und Serving mit AutoML
2. Integration des Modells mit Cloud Functions
3. Deployment der Applikation zur manuellen Nachbearbeitung mit App Engine

Diese werden wir im weiteren Verlauf des Artikels genauer beschreiben.

Voraussetzungen

Zum Ausführen der Schritte wird Zugang zu GCP benötigt. Wir empfehlen, hierfür ein neues Projekt anzulegen und die Google Cloud SDK auf der lokalen Entwicklungsumgebung einzurichten. Der vollständige Code zum Projekt kann aus dem Repository gcp-automated-quality-inspection heruntergeladen werden.

Außerdem wird eine Python-3.7-Umgebung (conda oder virtual env) benötigt. Die verwendeten Bibliotheken sind in der requirements.txt angegeben und können mit pip install -r requirements.txt installieren werden.

Vorbereitung, Training und Serving mit AutoML

Für unser Beispiel verwenden wir den Datensatz casting product data for quality inspection von Kaggle. Dieser beinhaltet Aufnahmen von Unterwasserpumpen-Bauteilen, die entweder als „okay“ oder „defect“ klassifiziert sind.

Um ein Modell mit AutoML zu trainieren, müssen die Daten zunächst in einen GCS Bucket hochgeladen werden. Da AutoML derzeit nur in der Region US-CENTRAL1 verfügbar ist, muss der Bucket für die Trainingsdaten dort erstellt werden. Dies kann mit dem folgenden Befehlen angelegt werden. Die GCP_PROJECT_ID findet man direkt in der GCP Console.

export GCP_REGION="US-CENTRAL1"
export GCP_PROJECT_ID="<fill-with-your-project-id>"
export TRAINING_DATA_BUCKET="${GCP_PROJECT_ID}""-product-quality"
gsutil mb -l $GCP_REGION gs://"${TRAINING_DATA_BUCKET}"

Nachdem die Daten von Kaggle heruntergeladen sind, werden diese entpackt und im data-Ordner gespeichert. Nach dem Entpacken hat das Verzeichnis die Struktur:

data
└── casting_data
    ├── test
    │   ├── def_front
    │   │   ├── ....
    │   │   └── new__0_9334.jpeg
    │   └── ok_front
    │       ├── ....
    │       └── cast_ok_0_9996.jpeg
    └── train
        ├── def_front
        │   ├── ...
        │   └── cast_def_0_9997.jpeg
        └── ok_front
            ├── ...
            └── cast_ok_0_9998.jpeg

Die Daten können nun mit dem folgenden Befehl in den Bucket geladen werden:

gsutil -m cp -r data/ gs://"${TRAINING_DATA_BUCKET}"

Für das Training des Modells mit AutoML wird eine CSV-Datei mit Metainformationen der Daten benötigt. Diese besteht aus den drei Spalten:

• SET: Bezeichnung, zu welchem Datensatz (Trainings-, Validierungs- oder Testdaten) das Tupel gehört. Mögliche Werte sind TRAIN, VALIDATION oder TEST. Es handelt sich hierbei um eine optionale Spalte. Falls die Daten nicht zugewiesen sind, teilt AutoML den Datensatz in das Verhältnis 8:1:1 ein.
• IMAGE_PATH: Der Key im GCS-Bucket.
• LABEL: Das Label des Tupels.

Die CSV-Datei kann direkt mit dem Python-Skript automl/prepare.py über python automl/prepare.py erstellt und mit gsutil cp preparation.csv gs://"${TRAINING_DATA_BUCKET}" hochgeladen werden.

Nun kann in AutoML der Datensatz erstellt werden. Dazu wird in der Console Single-Label Classification ausgewählt und anschließend die hochgeladene CSV-Datei ausgewählt. Dies führt den Import der Daten nach AutoML aus. Dieser Vorgang dauert ca. 20 Minuten.

Nach dem Import ist es möglich, die Daten in AutoML zu inspizieren. Dies ist vor allem hilfreich, um die Datenqualität selektiv zu begutachten. Jetzt kann das Training gestartet werden.

In unserem Fall wählen wir die Option „Cloud hosted“, um das Modell nach dem Training unkompliziert in GCP zu deployen. Die Rechenpower während des Trainings wird in sogenannten „Node Hours“ angegeben. Dahinter verbirgt sich eine Recheninstanz mit einer NVIDIA-Tesla-V100-Grafikkarte. Jede Node Hour wird mit 3,15 $ pro Stunde abgerechnet. Wir wählen das Minimum von acht Node Hours und starten das Training.

Nach dem Training kann in AutoML eine erste Evaluation des Modells durchgeführt werden. Hier kann man sich verschiedene Gütekriterien wie beispielsweise Recall, Precision und Confusion Matrix berechnen und anzeigen lassen. Weiterhin sind verschiedene Möglichkeiten gegeben, das Modell sowie dessen Vorhersagen interaktiv zu visualisieren.

Abschließend deployen wir das trainierte Modell als Service Endpoint.

Integration des Modells mit Cloud Functions

Die Integration des AutoML-Modells erfolgt über die zwei Cloud Functions Prediction und Moving. Für jeden Bild-Upload wird die Prediction-Funktion automatisch ausgeführt. Die Funktion lädt das Bild herunter und sendet es gegen den Modell-Endpoint. Anschließend schreibt die Funktion das Ergebnis auf ein Pub/Sub Topic. Hierdurch wird wiederum die Moving-Funktion getriggert. Diese beinhaltet die Logik, um die Bilder anhand des Klassifizierungsergebnisses zu sortieren.

Prediction

Zunächst erstellen wir den INBOUND_BUCKET und das PREDICTION_TOPIC.

export INBOUND_BUCKET="product-quality-inbound"
export PREDICTION_TOPIC="automl_predictions"
gsutil mb -l $GCP_REGION gs://"${INBOUND_BUCKET}"
gcloud pubsub topics create "${PREDICTION_TOPIC}"

Die Cloud Function ist in cloud_functions/predict/main.py implementiert. Während der Laufzeit wird das zu klassifizierende Bild vom Bucket heruntergeladen und an den AutoML Service Endpoint gesendet. Die Response im Protocol Buffer Format wird deserialisiert und anschließend auf das PREDICTION_TOPIC  in einer Nachricht der folgenden Form geschrieben.

msg = {
    "bucket_name": data["bucket"],
    "image_name": data["name"],
    "prediction_label": result.get("display_name"),
    "prediction_score": result.get("classification").get("score"),
}

Das Deployment erfolgt über die Google Cloud SDK. Dazu benötigt man die MODEL_ID des trainierten Modells, die in der AutoML-Oberfläche zu finden ist. Weiterhin wird als Trigger-Event google.storage.object.finalize mit dem dazugehörigen Bucket INBOUND_BUCKET angegeben.

export MODEL_ID="ICN690530685638672384"
export PREDICT_CLOUD_FUNCTION_PATH="cloud_functions/predict"
export PREDICT_CF_NAME="predict_image"
gcloud functions deploy "$PREDICT_CF_NAME" \
 --source "$PREDICT_CLOUD_FUNCTION_PATH" \
 --runtime python37 \
 --trigger-resource "$INBOUND_BUCKET" \
 --trigger-event google.storage.object.finalize \
 --set-env-vars model_id="$MODEL_ID",topic_id="$PREDICTION_TOPIC"

Moving

Die Moving Function verarbeitet Nachrichten vom PREDICTION_TOPIC. Sobald eine Nachricht eintrifft, löst das die Moving Cloud Function aus. Diese ist in cloud_functions/move/main.py implementiert und verarbeitet die Ergebnisse anhand der Konfidenz, dem Label und dem Schwellwert. Abhängig von diesen drei Werten wird das zugehörige Bild vom INBOUND_BUCKET in die spezifischen Verzeichnisse des PREDICTION_BUCKET bewegt:

• okay: Bilder, auf denen kein Fehler erkannt wurde.
• defect: Bilder, auf denen ein Fehler erkannt wurde.
• unclear: Bilder, bei denen sich das Modell unsicher ist. In diesem Fall liegt die Konfidenz unter dem gewünschten Schwellwert.

Vor dem Deployment muss zunächst der Prediction Bucket angelegt werden:

export PREDICTION_BUCKET="product-quality-prediction" 
gsutil mb -l $GCP_REGION gs://"${PREDICTION_BUCKET}"

Anschließend kann die Funktion mit den zugehörigen Umgebungsvariablen über die Google Cloud SDK deployt werden:

export PREDICTION_THRESHOLD="0.8"
export MOVE_CLOUD_FUNCTION_PATH="cloud_functions/move"
export MOVE_CF_NAME="move_image"
gcloud functions deploy "$MOVE_CF_NAME" \
 --source "$MOVE_CLOUD_FUNCTION_PATH" \
 --runtime python37 \
 --trigger-topic "$PREDICTION_TOPIC" \
 --set-env-vars prediction_bucket="$PREDICTION_BUCKET",prediction_threshold="$PREDICTION_THRESHOLD"

Deployment der Applikation zur manuellen Nachbearbeitung mit App Engine

Bei den unsicheren Fällen wird der Input von Facharbeiter*innen benötigt. Über eine simple Webapplikation stellen wir hierfür die Bilder aus dem unclear-Verzeichnis im Browser dar. So können die Bauteile im Detail kontrolliert und manuell eingeteilt werden.

Die folgende Abbildung zeigt die Architektur der Applikation.

Die Applikation ist in Python mit FastAPI entwickelt und liefert mittels einer statischen Webseite ein React Frontend aus. Die Implementierung befindet sich im app_engine- Verzeichnis. Das Deployment erfolgt über App Engine.

Vorbereitung der Berechtigungen

Bevor die Applikation deployt werden kann, benötigt die Anwendung verschiedene Berechtigungen. Zuerst muss App Engine in der Console für das Projekt aktiviert werden. Dadurch wird der Service Account ${PROJECT_ID}@appspot.gserviceaccount.com angelegt. Im IAM muss nun ein Key für den Service Account erstellt und im app_engine-Verzeichnis als app_engine_service_account.json gespeichert werden.

Beim Hochfahren der Anwendung wird der Key geladen , um die notwendigen Berechtigungen für die Applikation zu erhalten. Wichtig hierbei ist, dass dieser Key weder geteilt noch versioniert werden sollte.

Die Anwendung erstellt presigned-urls für die Bilder im PREDICTION_BUCKET, die anschließend im Web-Frontend geladen werden. Daher benötigt der Service Account die Role Service Account Token Creator.

Außerdem benötigt der Service Account Zugriff auf den PREDICTION_BUCKET. In der GCP Console navigieren wir dazu zum Storage Browser und erteilen dem Service Account die Rollen Storage Object Viewer und Storage Legacy Bucket Writer für den Bucket.

Deployment der Anwendung auf App Engine

Vor dem Deployment muss zunächst sichergestellt werden, dass sich im app_engine-Verzeichnis der Key app_engine_service_accout.json befindet. Zusätzlich muss der PREDICTION_BUCKET als Umgebungsvariable in app.yaml angepasst werden.

Anschließend wird die Applikation mit gcloud app deploy app_engine/app.yaml deployt. Sobald das Deployment abgeschlossen ist, kann die Applikation direkt aus der CLI mit dem Befehl gcloud app browse aufgerufen werden.

Die Applikation liest nun im PREDICTION_BUCKET das unclear-Verzeichnis aus. Um sie zu testen, kann ein Bild in das Verzeichnis hochgeladen werden. Nachdem das Bild manuell klassifiziert wurde, wird es im Verzeichnis human_decided mit dem Prefix des Labels abgespeichert.

Wie teuer ist der Betrieb dieses KI-Systems?

Eine wichtige Frage sind die Kosten, die bei dem Betrieb einer solchen Cloud-Anwendung anfallen. Hierbei unterscheiden wir zwischen einmaligen, fixen und dynamischen Kostenpunkten:

• Einmalig: Kosten wie beispielsweise das Modelltraining
• Fix: Kosten, die dafür anfallen, dass die Anwendung dauerhaft verfügbar ist. Zum Beispiel der Service Endpoint des Modells und Webanwendungen mit App Engine
• Dynamisch: Kosten, die je nach Benutzung und Auslastung anfallen, wie beispielweise Speicherplatz in GCS und Rechenzeit für Cloud Functions.

Die folgende Tabelle listet die Kostenpunkte des Systems ohne Bezug zum Netzwerk-Traffic:

Auflistung der Kosten ohne Netzwerktraffic

Einmalig	Fix	Dynamisch
AutoML: Modell-Training 3,15 $ pro Node Hour	AutoML: Modell-Deployment 1,25 $ pro Node Hour	GCS: – Datenspeicherung: 0,026 $ pro GB – Netzwerk (ausgehender Traffic): 0,12 $ pro GB – Schreiben und Auflisten pro Objekt (Klasse A): 0,05 $ pro 10.000 Vorgänge – Lesen und Abrufen pro Objekt (Klasse B): 0,004 $ pro 10.000 Vorgänge
	App Engine: B1 Instanz  pro Stunde und Instanz 0,05 $	Cloud Functions: – Aufrufe: 0,0000004 $ pro Aufruf – Rechenzeit bei 128 MB: 0,000000231 $ pro 100ms

Grundsätzlich ist es immer schwierig, ohne konkrete Use Case eine genaue Kalkulation der Kosten aufzustellen. Neben der Anzahl an Aufrufen spielt auch noch das Umfeld der Lösung eine wichtige Rolle.

Um dennoch eine initiale Vorstellung der Kosten zu konkretisieren, gehen wir von der folgenden Annahmen aus:

• Jeden Tag fallen 1.000 Bilder mit je 1 MiB an.
• 5 % der Bilder werden als unsicher klassifiziert.
• Die Anwendung läuft 24h am Tag über 30 Tage hinweg.

In diesem Kontext ergeben sich die nachfolgenden Kosten:

• Einmalig:
  • Modell-Training: 3,15 $ * 8 Node hour = 25,2 $
• Fix:
  • Modell-Deployment: 1,25 $ * 24 Stunden * 30 Tage = 900 $
  • App Engine Anwendung: 0,05 $ * 24 Stunden * 30 Tage = 36 $
• Dynamisch:
  • Die dynamischen Kosten fallen in unserem Beispiel nur marginal ins Gewicht, weshalb wir diese mit den folgenden Volumen abschätzen)
  • GCS: < 1,5 $
  • Cloud Functions:  < 1 $

Hierbei berücksichtigen wir das Free Tier von GCP nicht.

Aus der Rechnung geht klar hervor, dass das Modell-Deployment die höchsten Kosten verursacht. Diese Kosten können gegebenenfalls weiter reduziert werden, beispielsweise durch ein Edge-Deployment des Modells oder dadurch, das Modell nicht rund um die Uhr, sondern nur punktuell etwa zu den Arbeitszeiten laufen zu lassen.

Fazit

In diesem Blog-Artikel haben wir gezeigt, wie man in wenigen Schritten ein initiales KI-System zur Semi-Automatisierung in der Qualitätskontrolle, auf der Google Cloud Platform implementieren kann.

Durch den Einsatz von Cloud Computing Diensten können datengetriebene Produkte schnell prototypisiert werden. Hierbei ermöglichen es Services wie App Engine und Cloud Functions Entwickler*innen, sich mehr auf die eigentliche Wertschöpfung zu fokussieren als sich dem operativen Betrieb der Anwendungen auseinander zu setzen.

Insbesondere in der Bilderkennung kann heutzutage ein ausreichend gutes KI-Modell ohne mühsamen Aufwand entwickelt werden. Dadurch sinkt die Eintrittsbarriere zur Validierung datengetriebener Produkte. KI-Projekte können durch die technologischen Fortschritte in der Cloud-Entwicklung im Speedboot-Verfahren durchgeführt werden.

Unserer Herangehensweise an KI-Projekte haben wir in unserem On-Demand-Webinar (Deutsch) vorgestellt.

Jetzt einen unverbindlichen Austausch anfordern über ki@codecentic.de .