Designing and Implementing a Microsoft Azure AI Solution

Benutzerdefinierte Analyzer in Azure AI Search erlauben dir, eine eigene Pipeline zur Textanalyse zu definieren, indem du einen Tokenizer, null oder mehr Token-Filter und null oder mehr Zeichenfilter kombinierst. Das ist unverzichtbar, wenn du sprachspezifische Textverarbeitung brauchst, etwa wenn japanischer Text anders tokenisiert werden soll als englischer. Azure AI Search unterstützt integrierte Analyzer (darunter sprachspezifische wie `ja.microsoft` und `ja.lucene`), aber wenn du feingranulare Kontrolle darüber brauchst, wie Text in Tokens zerlegt und transformiert wird, definierst du einen benutzerdefinierten Analyzer in der Indexdefinition.

Ein benutzerdefinierter Analyzer wird im Index-Schema unter der Sammlung `analyzers` angegeben und verweist auf:

• Einen Tokenizer (z. B. den `ja.lucene`-Tokenizer für die morphologische Analyse des Japanischen)
• Token-Filter (z. B. Kleinschreibung, Stoppwörter, Stemming)
• Zeichenfilter (z. B. Mapping oder Musterersetzung, angewendet vor der Tokenisierung)

Damit hast du volle Kontrolle darüber, wie Textfelder indexiert und abgefragt werden.

Warum jede falsche Option nicht zutrifft:

• A (Suggesters): Suggesters ermöglichen Type-Ahead (Autovervollständigung) und Suchvorschläge. Sie steuern weder die Textanalyse noch die Tokenisierung.

• B (Synonym maps): Synonym maps definieren gleichbedeutende Begriffe (z. B. 'car' = 'automobile'), um die Trefferabdeckung bei Abfragen zu erweitern. Sie kümmern sich nicht um Tokenisierung oder sprachspezifische Pipelines zur Textanalyse.

• D (Scoring profiles): Scoring profiles passen an, wie Suchergebnisse gewichtet werden, indem bestimmte Felder verstärkt oder Funktionen angewendet werden (z. B. Aktualität, Entfernung). Bei der Textanalyse oder Tokenisierung spielen sie keine Rolle.

(Quelle: https://learn.microsoft.com/en-us/azure/search/index-add-custom-analyzers)

Der Bereich Playground im Microsoft Foundry-Portal (früher Azure AI Studio) ist die interaktive Umgebung, in der du Prompts mit deinen bereitgestellten Azure OpenAI-Modellen testen und iterativ verbessern kannst. Der Playground bietet verschiedene Modi, darunter den Chat playground für Konversationsmodelle (z. B. GPT-4, GPT-4o), den Completions playground für Textvervollständigung und den Playground für Bildgenerierung für DALL-E-Modelle. Im Playground kannst du Parameter wie temperature, max tokens, top_p sowie Frequency-/Presence-Penalties anpassen, System-Messages hinzufügen, Few-Shot-Prompts testen und den Tokenverbrauch einsehen.

Warum die anderen Optionen falsch wären (sofern angeboten):

• Deployments — Dieser Bereich dient der Verwaltung von Modellbereitstellungen (Deployments anlegen, skalieren, löschen), nicht dem interaktiven Testen von Prompts.
• Models catalog — In diesem Bereich kannst du verfügbare KI-Modelle durchsuchen und entdecken, er ist aber nicht für iteratives Prompt-Testing gegen ein bereitgestelltes Modell gedacht.
• Evaluations — Dieser Bereich dient dazu, die Modellqualität systematisch anhand von Evaluationsdatensätzen und Metriken zu bewerten, nicht dem spontanen Testen und Iterieren von Prompts.
• Prompt flow — Das ist ein Entwicklungswerkzeug zum Erstellen, Testen und Bereitstellen von KI-Workflows/-Pipelines und damit komplexer als einfaches Prompt-Testing.

Der Playground ist gezielt als interaktiver Testbereich konzipiert, in dem Entwickler schnell mit verschiedenen Prompts und Parametern experimentieren können, bevor sie das Modell in ihre Anwendungen integrieren.

(Quelle: https://learn.microsoft.com/en-us/azure/foundry/)

Custom Vision ist die richtige Wahl, wenn eine Organisation domänenspezifische Objekte erkennen oder klassifizieren muss, die von den vorgefertigten Modellen in Azure AI Vision Image Analysis 4.0 nicht abgedeckt werden. Mit Custom Vision kannst du eigene Modelle zur Bildklassifizierung und Objekterkennung mit deinen eigenen gelabelten Daten trainieren, was es ideal für spezialisierte Szenarien macht (z. B. das Erkennen bestimmter Fertigungsfehler, das Bestimmen bestimmter Pflanzenarten usw.).

Warum „Wenn es domänenspezifische Objekte erkennen muss, die von vorgefertigten Modellen nicht abgedeckt werden …“ richtig ist: Custom Vision ist gezielt für Szenarien gedacht, in denen die vorgefertigten Allzweckmodelle von Image Analysis 4.0 die für deine Geschäftsdomäne relevanten Objekte oder Kategorien nicht abdecken. Du lädst eigene Trainingsbilder hoch, labelst sie und trainierst ein auf deine Anforderungen zugeschnittenes eigenes Modell.

Warum „Wenn es Hintergrundentfernung braucht“ falsch ist: Hintergrundentfernung ist eine integrierte Funktion von Azure AI Vision Image Analysis 4.0 (konkret der Segment API). Dafür braucht es kein Custom Vision — sie ist sofort verfügbar.

Warum „Wenn es OCR-Funktionen braucht“ falsch ist: OCR (Optical Character Recognition) ist eine vorgefertigte Funktion von Azure AI Vision Image Analysis 4.0 (und der Read API). Für die Textextraktion aus Bildern braucht man kein Custom Vision.

Warum „Wenn es allgemeine Bildbeschreibungen braucht“ falsch ist: Allgemeine Bildbeschreibungen sind eine vorgefertigte Funktion von Azure AI Vision Image Analysis 4.0. Die Features Dense Captions und Caption liefern automatische Beschreibungen von Bildinhalten ganz ohne eigenes Training.

Der Kern ist, den Unterschied zwischen vorgefertigten KI-Funktionen (Image Analysis 4.0) und selbst trainierten Modellen (Custom Vision) zu verstehen. Nutze vorgefertigte Modelle, wenn sie dein Szenario abdecken; nutze Custom Vision, wenn du domänenspezifische Erkennung oder Klassifizierung brauchst.

(Quelle: https://learn.microsoft.com/en-us/azure/ai-services/computer-vision/overview und https://learn.microsoft.com/en-us/azure/ai-services/custom-vision-service/overview)

Modellinterpretierbarkeit umzusetzen und Transparency Notes zu erstellen ist der richtige Ansatz, um sicherzustellen, dass KI-Entscheidungen gegenüber Stakeholdern erklärt werden können. Die Responsible-AI-Prinzipien von Microsoft betonen Transparenz und Erklärbarkeit als zentrale Säulen. Transparency Notes sind von Microsoft für seine KI-Dienste veröffentlichte Dokumente, die Stakeholdern helfen zu verstehen, wie die KI-Technologie funktioniert, welche Entscheidungen Systembetreiber treffen können, die die Leistung beeinflussen, und wo die Grenzen der Technologie liegen. Werkzeuge zur Modellinterpretierbarkeit (etwa InterpretML, SHAP und LIME in Azure Machine Learning) erlauben Entwicklern und Stakeholdern nachzuvollziehen, warum ein Modell eine bestimmte Vorhersage getroffen hat. Zusammen sorgen diese Praktiken dafür, dass KI-Entscheidungen nicht undurchsichtig sind und gegenüber Business-Stakeholdern, Regulierungsbehörden und Endnutzern begründet werden können.

Warum jede falsche Option falsch ist:

A) Ausschließlich Black-Box-Modelle verwenden — Black-Box-Modelle sind das Gegenteil von erklärbarer KI. Sie liefern Ergebnisse, ohne Einblick zu geben, wie Entscheidungen zustande kommen, was es schwerer (nicht leichter) macht, KI-Entscheidungen gegenüber Stakeholdern zu erklären.

B) Die Modellkomplexität erhöhen — Höhere Modellkomplexität verringert in der Regel die Interpretierbarkeit. Komplexere Modelle (z. B. tiefe neuronale Netze mit vielen Schichten) sind schwerer zu erklären, was dem Ziel entgegenwirkt, KI-Entscheidungen verständlich zu machen.

C) Sämtliches Logging und Monitoring entfernen — Logging und Monitoring zu entfernen beseitigt Audit-Trails und Nachvollziehbarkeit, die wesentliche Bestandteile von Responsible-AI-Governance sind. Ohne Logs gibt es keine Möglichkeit, vergangene KI-Entscheidungen zu prüfen oder zu erklären.

(Quelle: https://learn.microsoft.com/en-us/azure/machine-learning/concept-responsible-ai und https://learn.microsoft.com/en-us/legal/cognitive-services/openai/transparency-note)