Azure Custom Vision: Wie trainierst und betreibst du Bildklassifikation in einer Azure Function?

Mit Custom Vision kommst du schnell von gelabelten Bildern zu einem Vorhersage-Endpoint. Die Produktarbeit beginnt nach dem Happy Path: schlechte Uploads, Antworten mit niedriger Konfidenz, Iterationen, die den veröffentlichten Endpoint kaputtmachen, und keine Spuren, wenn das Label falsch ist.

Halte die UI langweilig: hochladen, vorhersagen, Label und Konfidenz anzeigen. Steck die Komplexität in Datenqualität, Validierung, Request-Limits, Logging und einen kontrollierten Veröffentlichungsweg für neue Iterationen.

Abbildung 1. Hochladen, vorhersagen, erklären, iterieren. Die UI bleibt absichtlich einfach. Die Betreibbarkeit steckt in der Validierung, der Grenze der API, ehrlicher Konfidenz und einem Veröffentlichungsweg, den du zurückrollen kannst.

Kontext und Rahmenbedingung

Ich habe zu viele Vision-Demos gesehen, die poliert aussehen, bis zum ersten schlechten Upload, zur ersten Antwort mit niedriger Konfidenz oder zur ersten Modelliteration, die den veröffentlichten Endpoint kaputtmacht. Eine gute Demo wird zum Produkt, wenn Eingabevalidierung, Request-Limits, Logging und ein Weg zum Nachtrainieren vom ersten Tag an bestehen bleiben.

Custom Vision (oder der gleichwertige Weg zur Bildklassifikation auf Azure, den du unter Microsoft Foundry / Azure AI Services wählst) sollte die Vorhersage verantworten. Die Web-App sollte die Upload-Hygiene verantworten, die Authentifizierung, falls du sie brauchst, die Darstellung von Labels und Konfidenz und die betrieblichen Spuren, mit denen du falsche Antworten später debuggen kannst. Wenn die UI clever sein will, hören die Leute auf, dem Score zu vertrauen. Wenn das Backend die Grundlagen auslässt, kannst du die Cleverness, die du ausgeliefert hast, nicht betreiben.

Abbildung 2 ist die Oberfläche aus Learn, die den Vertrag mit dem Nutzer sichtbar macht: Labels und Konfidenz, keine zweite Geschichte, die sich die App-Hülle ausdenkt.

Abbildung 2. Labels und Konfidenz sind der Vertrag mit dem Nutzer. In der Trainingsoberfläche wird iteriert. Die Web-App sollte sich keine zweite Geschichte ausdenken. Quelle: Microsoft Learn: Custom Vision overview.

Abbildung 3 ist die Projektstartseite, auf der die Iterationen liegen. Behandle einen veröffentlichten Endpoint als Release-Artefakt, nicht als beiläufiges Überschreiben nach dem Mittagessen.

Abbildung 3. Iterationen leben in der Projektoberfläche. Behandle veröffentlichte Endpoints als Release-Artefakte, nicht als beiläufiges Überschreiben. Quelle: Microsoft Learn: Custom Vision overview.

1. Mit dem Nutzerfluss anfangen, nicht mit der Model Card

Der Ablauf sollte offensichtlich sein: Bild auswählen, absenden, Ergebnis sehen. Ein minimales Layout hält den Fokus auf der Kerninteraktion. Zusätzliche Schalter, erweiterte Panels und dekorative Diagramme können warten, bis der Happy Path langweilig zuverlässig ist. Wenn der Ablauf kompliziert ist, wirkt die KI-Funktion schwieriger, als sie ist. Abbildung 1 ist dieser langweilige Pfad, gezeichnet als vier Aufgaben.

2. Validieren, bevor du einen Inferenzaufruf ausgibst

Prüf Dateityp, Größe und grundlegende Dekodierbarkeit des Bildes auf dem Server. Lehne klar ab. Schick keine beliebigen Blobs an den Vorhersage-Endpoint in der Hoffnung, dass es gut geht. Validierung schützt die Kosten, schützt den Dienst vor Müll und gibt Nutzern einen schnelleren Fehler als einen Timeout, der als "something went wrong" verpackt ist.

3. Die Vorhersage in langweiliges, vorhersehbares Backend-Verhalten verpacken

Timeouts, Retries bei vorübergehenden Fehlern und gemappte Fehlerantworten gehören in die API-Schicht. Gib verständliche Fehlermeldungen zurück, wenn die Inferenz scheitert. Zeig Label und Konfidenz in verständlicher Sprache, wenn sie gelingt. Niedrige Konfidenz ist ein vollwertiges Ergebnis: Sag es in der UI, statt so zu tun, als wäre das oberste Label unumstößlich.

4. Secrets und Keys aus dem Browser heraushalten

Keys für Vorhersage und Training gehören auf den Server oder in Muster mit Managed Identity, nicht in Frontend-Bundles. Eine statische Seite, die Custom Vision direkt aufruft, ist ein kurzer Weg zu geleakten Keys und unkontrolliert verbrauchtem Kontingent. Der Browser lädt in deine App hoch. Deine App ruft Azure auf. Abbildung 4 ist die Aufteilung der Verantwortung, die den Key aus dem Quelltext der Seite heraushält.

Abbildung 4. Der Browser spricht mit deiner App. Deine App spricht mit Custom Vision. Keys und Managed Identity bleiben auf dem Server. Ein Key im Browser ist der Weg, auf dem der Kontingentverbrauch einen stillen Besitzer bekommt.

5. Genug loggen, um schlechte Ergebnisse zu debuggen

Speichere Correlation IDs, Modellname oder Iteration ID, Latenz, die obersten Labels und, falls du das erfasst, ob der Nutzer das Ergebnis akzeptiert oder korrigiert hat. Du brauchst das Rohbild nicht für immer in jeder Umgebung, aber du brauchst einen Weg, eine Klasse von Fehlern zu reproduzieren. Ohne Iteration IDs in den Logs wird die Ursachenanalyse nach der nächsten Veröffentlichung zur Folklore.

6. Iterationen von Custom Vision als Release behandeln

Neue Tags, neue Trainingsbilder und eine neu veröffentlichte Iteration ändern das Verhalten des Produkts. Bring Iterationen so voran wie App-Builds: notier, was sich geändert hat, teste einen festen Bildersatz als Smoke-Test und behalte einen Rollback auf die vorher veröffentlichte Iteration. Enge Klassifikatoren driften, wenn sich die Welt ändert. Plane diese Drift ein, statt sie in einem Stakeholder-Meeting zu entdecken. Abbildung 5 ist die Form des Release.

Abbildung 5. Trainieren, Smoke-Test, veröffentlichen, live. Der gestrichelte Rückweg ist der Rollback auf die vorher veröffentlichte Iteration. Logge bei jeder Vorhersage die Iteration ID, damit sich eine schlechte Veröffentlichung diagnostizieren lässt.

Häufige Fehler

Nur der Happy Path der Demo. Ein PNG mit einem klaren Objekt auf weißem Hintergrund. Echte Nutzer laden HEIC-Fotos vom Handy hoch, Screenshots und Scans mit fünf Megabyte. Die App verschluckt sich, oder das Modell zuckt mit den Schultern.

Konfidenz ignoriert. Immer das oberste Label fett anzeigen. Nutzer vertrauen 0.41 genauso wie 0.97. So bekommen falsche betriebliche Entscheidungen eine hübsche UI.

Keys im Browser. Jemand schaut in den Quelltext, kopiert den Vorhersage-Key, und deine Rechnung erklärt sich im nächsten Monat von selbst. Abbildung 4 macht diesen Fehler sichtbar.

Keine Disziplin bei Iterationen. Im Portal nachtrainieren, veröffentlichen und hoffen. Die Smoke-Bilder von gestern werden jetzt falsch klassifiziert, und niemand kann sagen, welche Veröffentlichung das war. Abbildung 5 ist die Disziplin, die das verhindert.

Logging ohne Identität des Modells. Du weißt, dass der Request fehlgeschlagen ist oder seltsam aussah. Du weißt nicht, welche Iteration ihn beantwortet hat. Support wird zur Archäologie.

Unbegrenzte Uploads. Kein Größenlimit, kein Rate Limit, keine Authentifizierung bei einem internen Tool, das irgendwie extern geworden ist. Inferenzkosten und Missbrauch kommen zusammen.

So übernehmen oder anpassen

So übernehmen

• Serverseitige Validierung von Typ, Größe und Dekodierbarkeit vor der Vorhersage.
• Zugangsdaten für die Vorhersage nur im Backend. Der Browser spricht mit der API der App.
• Die UI zeigt immer Label plus Konfidenz. Die Schwelle für niedrige Konfidenz legt das Produkt fest.
• Logs enthalten Correlation ID, Iteration oder Modell-ID, Latenz und die Top-N-Labels.
• Veröffentlichte Iterationen werden als Releases mit Smoke-Set und Rollback behandelt.
• Rate Limits und Authentifizierung sind für interne und öffentliche Erreichbarkeit dokumentiert.
• Verantwortung für das Nachtrainieren und Regeln zur Datenaufbewahrung stehen fest, bevor der erste Upload in Produktion kommt.

Vor dem Einsatz anpassen

Custom Vision ist für eine eng gefasste Aufgabe schnell aufgesetzt. Es ist kein Ersatz für einen sorgfältig gebauten Vision-Stack, wenn du Detektion, Segmentierung oder strenge Latenz am Edge brauchst. Wähle es, wenn gelabelte Beispiele und eine Klassifikationsantwort für die Produktentscheidung reichen.

Eine dünne Web-App ist leicht zu erklären und leicht zu ersetzen. Eine dickere Produkthülle (Authentifizierung, Verlauf, Queue für menschliche Prüfung) dauert länger, ist aber das, was interne Tools nach der zweiten Woche oft brauchen. Tu nicht so, als wäre die Upload-Seite das ganze System, wenn Prüfer Labels für das Nachtrainieren korrigieren müssen.

Ob du das Modell über Azure hostest oder für Edge-Runtimes exportierst, ändert, wie du Updates und den Offline-Betrieb löst. Entscheide danach, wohin Bilder wandern dürfen, nicht danach, welchen Quickstart du zuerst eingefügt hast.

Wichtigste Quellen: Microsoft Learn zu Custom Vision, Bildklassifikation und Authentifizierungsmuster für Azure AI / AI Services, die Keys aus dem Browser heraushalten. Verwende die aktuellen Namen von Microsoft Foundry, wenn dein Deployment-Ziel unter dieses Dach gewandert ist.

Hochladen. Vorhersagen. Erklären. Iterieren. Vier Aufgaben. Ein Score, dem der Nutzer tatsächlich vertrauen kann.

Verwandte Notizen

• Pose Estimation: MediaPipe oder YOLOPose für Echtzeit-Posenklassifikation? (eine Echtzeit-Vision-Schleife mit ihrem eigenen Latenzbudget)