Microsoft Azure Data Scientist Associate
Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der DP-100-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Benötigen eine zentralisierte, kollaborative Plattform für den gesamten Machine Learning-Lebenszyklus, von der Datenvorbereitung bis zur Bereitstellung und Überwachung.
Azure Machine Learning-Arbeitsbereich.
Warum: Er ist der grundlegende Dienst, der alle erforderlichen Komponenten integriert: Compute, Datastores, Umgebungen, Experiment-Tracking, Modellregister und Endpunkte.
Erfordern, dass der gesamte ML-Arbeitsbereichsverkehr, einschließlich zu abhängigen Ressourcen wie Storage und ACR, im privaten Azure-Netzwerk verbleibt und nicht dem öffentlichen Internet ausgesetzt ist.
Konfigurieren Sie den Azure ML-Arbeitsbereich mit einem verwalteten virtuellen Netzwerk und verwenden Sie private Endpunkte für den Arbeitsbereich und alle seine abhängigen Ressourcen (Storage, Key Vault, ACR).
Warum: Private Endpunkte bieten eine sichere, private Konnektivität zu Azure-Diensten und stellen sicher, dass der Datenverkehr nicht über das öffentliche Internet geleitet wird. Ein verwaltetes VNet vereinfacht diese Konfiguration für ML-Compute.
Die ML-Lösung muss strenge Regeln zur Datenresidenz einhalten, die sicherstellen, dass alle Daten und Rechenressourcen innerhalb einer bestimmten geografischen Region (z. B. Europäische Union) verbleiben.
Erstellen Sie den Azure ML-Arbeitsbereich, alle zugehörigen Speicherkonten und Compute-Ressourcen in einer Region innerhalb des erforderlichen geografischen Gebiets. Verwenden Sie Netzwerkisolation, um Datenexfiltration zu verhindern.
Warum: Azure-Ressourcen sind an die Region gebunden, in der sie erstellt werden. Dies gewährleistet die Einhaltung der physischen Datenstandortbestimmungen. Netzwerkisolation (verwaltetes VNet) verhindert, dass Daten außerhalb dieser Grenze verarbeitet werden.
Organisatorische Standards für alle ML-Arbeitsbereiche durchsetzen, wie z. B. die Anforderung von Kostenzuordnungstags, die Einschränkung von VM-Größen oder die Vorschrift zum Versand von Diagnoseprotokollen.
Verwenden Sie Azure Policy, um Regeln für die Ressourcenerstellung und -konfiguration anzuwenden und durchzusetzen.
Warum: Azure Policy bietet skalierbare, zentralisierte Governance. Es verhindert die Erstellung nicht-konformer Ressourcen und gewährleistet konsistente Standards ohne manuelle Überwachung.
Zugriff auf Daten in Azure Storage von einem ML-Arbeitsbereich aus, ohne Anmeldeinformationen (Kontoschlüssel, SAS-Token) im Code oder in der Konfiguration zu speichern.
Erstellen Sie die Datastore-Verbindung mithilfe identitätsbasierter Authentifizierung. Weisen Sie der verwalteten Identität des Arbeitsbereichs (oder der Benutzer-/Compute-Identität) die entsprechende RBAC-Rolle (z. B. Storage Blob Data Reader) für das Speicherkonto zu.
Warum: Dies ist ein passwortloses Zero-Trust-Muster, das Azure AD zur Authentifizierung verwendet, wodurch die Sicherheit verbessert und die Anmeldeinformationsverwaltung vereinfacht wird.
Mehrere Teams arbeiten an Projekten mit unterschiedlichen Sicherheitsstufen (z. B. PII vs. anonymisierte Daten). Es muss eine Ressourcenisolation bereitgestellt werden.
Erstellen Sie separate Azure ML-Arbeitsbereiche für jede Sicherheitsgrenze. Ein Arbeitsbereich für PII-Projekte sollte eine strengere Netzwerkisolation aufweisen als einer für nicht-sensible Projekte.
Warum: Der Arbeitsbereich ist die primäre Sicherheits- und Isolationsgrenze. Die Trennung nach Sicherheitsstufe ist eine Best Practice, um Datenlecks zu verhindern und geeignete Kontrollen anzuwenden.
Entwicklungs-/Experimentieraktivitäten müssen von der produktionsreifen Modellschulung und -bereitstellung getrennt werden, um Interferenzen zu vermeiden und Stabilität zu gewährleisten.
Verwenden Sie separate Azure ML-Arbeitsbereiche für Entwicklungs- und Produktionsumgebungen.
Warum: Dies isoliert Produktionsressourcen, -daten und -modelle von experimentellen Arbeiten und bietet Stabilität und klare Governance für Produktions-MLOps-Pipelines.
Bereitstellung von Compute-Ressourcen für ML-Trainingsjobs, die intermittierend ausgeführt werden, mit hoher Priorität auf Kostenminimierung.
Verwenden Sie einen Azure ML-Compute-Cluster mit VMs niedriger Priorität, einer Mindestknotenanzahl von 0 und konfigurierter Auto-Skalierung.
Warum: VMs niedriger Priorität bieten erhebliche Kosteneinsparungen für unterbrechbare Workloads. Ein Minimum von 0 Knoten stellt sicher, dass Sie nichts bezahlen, wenn der Cluster im Leerlauf ist.
Es müssen Compute-Ressourcen sowohl für die interaktive Notebook-Entwicklung durch einzelne Datenwissenschaftler als auch für die Ausführung größerer, unbeaufsichtigter Trainingsjobs bereitgestellt werden.
Stellen Sie Compute-Instanzen für die interaktive Entwicklung (eine pro Benutzer) bereit. Stellen Sie Compute-Cluster für Batch-Trainingsjobs bereit.
Warum: Compute-Instanzen sind persistente Single-User-VMs, die für interaktives Arbeiten optimiert sind. Compute-Cluster sind auto-skalierende, Multi-Node-Ressourcen, die für Batch-Jobs optimiert sind.
Sicherstellen, dass ML-Trainingsläufe reproduzierbar sind, indem alle Softwareabhängigkeiten, einschließlich spezifischer Python-Paketversionen, erfasst werden.
Definieren Sie eine Azure ML-Umgebung mithilfe einer conda-Umgebungs-YAML-Datei oder eines Dockerfiles. Registrieren und versionieren Sie diese Umgebung für die Verwendung in Trainingsjobs.
Warum: Umgebungen sind versionierte, wiederverwendbare Spezifikationen einer Laufzeit. Dies entkoppelt die Umgebung vom Compute und stellt sicher, dass jeder Lauf mit dieser Umgebungsversion identisch ist.
Die Logik des Feature Engineering muss zwischen Training und Inferenz konsistent sein, und Features sollten über mehrere Modelle und Teams hinweg wiederverwendbar sein.
Verwenden Sie Azure ML Managed Feature Store, um Features zu definieren, zu berechnen und bereitzustellen.
Warum: Ein Feature Store gewährleistet Konsistenz (verhindert Training-Serving Skew), ermöglicht die Feature-Erkennung und -Wiederverwendung und bietet sowohl Offline- (für das Training) als auch Online-Speicher (für Inferenz mit geringer Latenz).
Alle ML-Experimente systematisch verfolgen, einschließlich Code-Versionen, Hyperparametern, Metriken und Modellartefakten, zum Vergleich und zur Reproduzierbarkeit.
Verwenden Sie MLflow, das nativ in Azure ML integriert ist. Aktivieren Sie Autologging oder verwenden Sie explizite `mlflow.log_*`-Befehle im Trainingsskript.
Warum: MLflow bietet ein standardisiertes Open-Source-Framework für das Experiment-Tracking. Azure ML fungiert als verwalteter MLflow-Tracking-Server und bietet eine Benutzeroberfläche zum Vergleichen von Läufen.
Trainieren eines Klassifikationsmodells auf einem Datensatz mit einer starken Klassenungleichheit (z. B. Betrugserkennung), was zu einer schlechten Leistung bei der Minderheitsklasse führt.
Wenden Sie Techniken wie SMOTE (Synthetic Minority Over-sampling Technique) auf die Trainingsdaten an. Bewerten Sie das Modell mithilfe von Metriken, die unempfindlich gegenüber Ungleichgewicht sind, wie Precision-Recall AUC oder F1-Score.
Warum: Die einfache Verwendung der Genauigkeit ist irreführend. SMOTE erstellt synthetische Minderheitenstichproben, um dem Modell beim Lernen zu helfen, und PR-AUC/F1-Score misst die Leistung der positiven Klasse korrekt.
Es müssen optimale Hyperparameter für ein Modell mit langer Trainingszeit und begrenztem Compute-Budget gefunden werden.
Verwenden Sie einen Sweep-Job mit Bayes'scher Stichprobenziehung und einer frühzeitigen Abbruchrichtlinie (z. B. Bandit oder Median Stopping).
Warum: Bayes'sche Stichprobenziehung erkundet den Suchraum intelligent und konzentriert sich auf vielversprechende Regionen. Eine frühzeitige Beendigung stoppt schlecht performende Läufe frühzeitig und spart erhebliche Compute-Zeit und Kosten.
Ein Zeitreihen-Vorhersagemodell mit AutoML erstellen.
Konfigurieren Sie den AutoML-Job mit `task='forecasting'`, geben Sie den `time_column_name` an und legen Sie den `forecast_horizon` fest.
Warum: Die Angabe der Aufgabe als "forecasting" (Prognose) ermöglicht es AutoML, zeitreisenspezifische Techniken wie die Generierung von Lag-Features, die Erkennung von Saisonalität und die zeitbewusste Kreuzvalidierung anzuwenden.
Trainieren eines großen Deep-Learning-Modells über mehrere GPUs auf mehreren Compute-Knoten, um die Trainingszeit zu reduzieren.
Verwenden Sie einen Compute-Cluster mit GPU-fähigen Knoten. Konfigurieren Sie im Befehlsjob die `distribution`-Eigenschaft (z. B. `type: "PyTorch"`, `process_count_per_instance: <# GPUs>`).
Warum: Azure ML vereinfacht das verteilte Training durch die Verwaltung der Knotenkonfiguration und -kommunikation. Die `distribution`-Konfiguration teilt Azure ML mit, wie die verteilten Trainingsprozesse gestartet werden sollen.
Automatisierung eines mehrstufigen ML-Workflows (z. B. Datenvorbereitung, Training, Evaluierung), der mit verschiedenen Parametern wiederverwendet werden kann.
Definieren Sie eine Azure ML-Pipeline mit Komponenten für jeden Schritt. Verwenden Sie Pipeline-Eingaben, um den Workflow zu parametrisieren.
Warum: Komponentenbasierte Pipelines fördern Modularität und Wiederverwendbarkeit. Sie unterstützen auch die automatische Schritt-Zwischenspeicherung (Wiederverwendung), was Zeit spart, indem Schritte, deren Eingaben sich nicht geändert haben, nicht erneut ausgeführt werden.
Ein Modell performt sehr gut auf dem Trainingsset, aber schlecht auf dem Validierungsset, was durch eine divergierende Trainings- und Validierungsverlustkurve angezeigt wird.
Dies ist ein klassisches Zeichen für Overfitting. Abhilfe schaffen Sie durch die Anwendung von Regularisierung (z. B. Dropout, L2), Datenaugmentation, Implementierung von Early Stopping oder Reduzierung der Modellkomplexität.
Warum: Die Lücke zwischen Trainings- und Validierungsleistung zeigt, dass das Modell die Trainingsdaten auswendig gelernt hat, anstatt zu generalisieren. Regularisierungstechniken bestrafen Komplexität, um die Generalisierung zu verbessern.
Ein lang laufender Trainingsjob auf VMs niedriger Priorität (Spot-VMs) ist dem Risiko ausgesetzt, präemptiert zu werden und den Fortschritt zu verlieren.
Implementieren Sie Checkpointing im Trainingsskript, um den Modell- und Optimiererzustand regelmäßig im Verzeichnis `./outputs` zu speichern.
Warum: Das Verzeichnis `./outputs` wird von Azure ML automatisch persistent gespeichert. Das Speichern von Checkpoints ermöglicht die Wiederaufnahme des Jobs vom zuletzt gespeicherten Zustand bei Präemption, wodurch der Fortschritt erhalten und Kosten gespart werden.
Eine Organisation hat eine Richtlinie, dass nur bestimmte ML-Algorithmen in der Produktion verwendet werden dürfen. Dies muss während der AutoML-Läufe durchgesetzt werden.
Verwenden Sie in der AutoML-Konfiguration den Parameter `blocked_models`, um nicht genehmigte Algorithmen explizit aus dem Suchraum auszuschließen.
Warum: Dies bietet eine direkte, durchsetzbare Möglichkeit, AutoML an Governance-Richtlinien anzupassen und die Auswahl nicht-konformer Modelle zu verhindern.
Bereitstellung eines Modells für Echtzeit-Vorhersagen mit geringer Latenz (<100ms) und hoher Verfügbarkeit.
Bereitstellung des Modells an einem Azure ML Managed Online Endpoint.
Warum: Verwaltete Online-Endpunkte sind ein vollständig verwalteter Dienst, der für Echtzeit-Inferenz optimiert ist und Auto-Skalierung, Lastverteilung, Blue/Green-Deployments und integriertes Monitoring bietet.
Asynchrones Scoring großer Datenmengen (Millionen von Datensätzen), wobei Kosteneffizienz Priorität hat.
Stellen Sie das Modell an einem Azure ML Batch Endpoint bereit.
Warum: Batch-Endpunkte sind für den asynchronen Hochdurchsatz-Score großer Datensätze konzipiert. Sie können skalierbare Compute-Cluster verwenden, die im Leerlauf auf null heruntergefahren werden, um Kosten zu optimieren.
Bereitstellung einer neuen Modellversion unter Minimierung des Risikos. Der Datenverkehr soll schrittweise auf die neue Version umgeleitet werden, und ein einfaches Rollback soll möglich sein.
Verwenden Sie einen einzelnen verwalteten Online-Endpunkt mit zwei Deployments (z. B. "blau" für das alte Modell, "grün" für das neue). Verwenden Sie Traffic Splitting, um den Prozentsatz der Anfragen zu steuern, die an jedes Deployment gehen.
Warum: Dieses Blue/Green-Deployment-Muster ermöglicht sichere Rollouts ohne Ausfallzeiten. Sie können das neue Modell an einem kleinen Teil des Live-Datenverkehrs validieren, bevor Sie sich für eine vollständige Umstellung entscheiden.
Verpacken eines Modells mit seinen Abhängigkeiten und Artefakten auf standardisierte, Framework-agnostische Weise für die Bereitstellung.
Verwenden Sie das MLflow-Modellformat. Fügen Sie bei der Registrierung des Modells die conda.yaml- oder requirements.txt-Datei sowie alle notwendigen Code-Artefakte hinzu.
Warum: MLflow bietet eine Standardkonvention für die Modellpaketierung, die Azure ML nativ versteht. Dies vereinfacht die Bereitstellung, da Azure ML die erforderliche Umgebung automatisch erstellen kann.
Ein bereitgestelltes Modell hat eine hohe Latenz, da es bei jeder Vorhersageanfrage große Hilfsdateien (z. B. einen großen Featurizer) lädt.
Verschieben Sie die Dateiladelogik von der `run()`-Funktion in die `init()`-Funktion im Scoring-Skript.
Warum: Die `init()`-Funktion wird nur einmal beim Start des Containers ausgeführt. Das Laden von Assets hier macht sie global für alle `run()`-Aufrufe verfügbar und vermeidet redundantes Laden bei jeder Anfrage.
Ein Echtzeit-Endpunkt erfährt variablen Datenverkehr (hohe Spitzen, niedrige Tiefen). Die Leistung muss kostengünstig aufrechterhalten werden.
Konfigurieren Sie die Auto-Skalierung für das bereitgestellte Managed Online Endpoint. Legen Sie eine minimale und maximale Anzahl von Instanzen fest und definieren Sie eine Skalierungsregel basierend auf der CPU-Auslastung oder der Anfragelatenz.
Warum: Die Auto-Skalierung passt die Anzahl der Compute-Instanzen automatisch an die Verkehrslast an und gewährleistet so die Leistung während Spitzenzeiten und spart Kosten in Zeiten geringerer Auslastung.
Eine Modellbereitstellung erfordert spezifische Systembibliotheken, benutzerdefinierte CUDA-Versionen oder einen benutzerdefinierten Inferenzserver, die in den Standard-Azure ML-Images nicht vorhanden sind.
Erstellen Sie ein benutzerdefiniertes Dockerfile, das ein Azure ML-Basis-Inferenzimage erweitert, fügen Sie die erforderlichen Abhängigkeiten hinzu, bauen Sie es und pushen Sie es in die Azure Container Registry. Verweisen Sie in der Bereitstellungsumgebung auf dieses Image.
Warum: Das Erweitern eines Basisimages bietet volle Kontrolle über die Laufzeitumgebung bei gleichzeitiger Kompatibilität mit der Serving-Infrastruktur von Azure ML.
Automatisierung des End-to-End-ML-Lebenszyklus, einschließlich Retraining, Evaluierung und Bereitstellung, ausgelöst durch Code- oder Datenänderungen.
Verwenden Sie Azure DevOps oder GitHub Actions, integriert mit der Azure ML CLI v2, um eine CI/CD-Pipeline zu erstellen. Die Pipeline sollte ein Qualitäts-Gate enthalten, das das neue Modell vor der Bereitstellung mit einem Baseline-Modell vergleicht.
Warum: Dieses MLOps-Muster automatisiert den ML-Workflow und gewährleistet Konsistenz, Qualität und schnelle Iteration. Das Qualitäts-Gate verhindert Modellleistungs-Regressionen.
Die Leistung eines Produktionsmodells verschlechtert sich aufgrund von Änderungen in der Eingabedatenverteilung. Das Modell muss automatisch neu trainiert werden, wenn eine signifikante Drift erkannt wird.
Konfigurieren Sie einen Azure ML Data Drift Monitor am Endpunkt. Richten Sie eine Warnung ein, die eine Azure Logic App oder Azure Function auslöst, welche wiederum die Retraining-Pipeline startet.
Warum: Dies schafft ein geschlossenes MLOps-System, das die Modellrelevanz als Reaktion auf sich ändernde Datenmuster automatisch aufrechterhält, ohne manuelles Eingreifen.
Eine neu bereitgestellte Modellversion erweist sich in der Produktion als fehlerhaft. Es muss schnell zur vorherigen stabilen Version zurückgekehrt werden.
Bei Verwendung eines Blue/Green-Deployments leiten Sie 100 % des Datenverkehrs zurück zum stabilen Deployment. Alternativ aktualisieren Sie den Endpunkt, um die vorherige Modellversion aus dem Modellregister erneut bereitzustellen.
Warum: Traffic Shifting ermöglicht ein sofortiges Rollback. Die erneute Bereitstellung einer Version aus dem Register ist ebenfalls eine schnelle und zuverlässige Methode, um einen bekannten guten Zustand wiederherzustellen.
Es müssen sowohl der operative Zustand (Latenz, Fehler) als auch die prädiktive Qualität (Data Drift, Genauigkeit) eines bereitgestellten Modells überwacht werden.
Aktivieren Sie die Application Insights-Integration am Endpunkt für operative Metriken. Konfigurieren Sie die Azure ML-Datensammlung und Data Drift Monitoring für Modellqualitätsmetriken.
Warum: Dieser zweigleisige Ansatz bietet eine vollständige Ansicht der Modellgesundheit. App Insights verfolgt die Systemleistung, während die Datensammlung/Drift-Überwachung die prädiktive Leistung des Modells verfolgt.
Der Modellendpunkt fällt aufgrund falsch formatierter oder unerwarteter Eingabedaten von Clients aus.
Implementieren Sie die Eingabevalidierungslogik innerhalb der `run()`-Funktion des Scoring-Skripts. Überprüfen Sie Datentypen, Bereiche und Strukturen und geben Sie einen aussagekräftigen Fehler (z. B. HTTP 400) für ungültige Anfragen zurück.
Warum: Serverseitige Validierung schützt das Modell vor Abstürzen und liefert den API-Konsumenten klares, sofortiges Feedback, wodurch der Dienst robuster wird.
Es muss verstanden werden, warum ein komplexes "Black-Box"-Modell bestimmte Vorhersagen trifft, zur Fehlersuche, Compliance oder zum Vertrauen der Stakeholder.
Verwenden Sie das Responsible AI-Dashboard in Azure ML, um Modellerklärungen zu generieren. Verwenden Sie SHAP für lokale (individuelle Vorhersage-) Erklärungen und die globale Feature-Wichtigkeit für das Gesamtverhalten des Modells.
Warum: SHAP-Werte bieten eine robuste, modellagnostische Methode, um den Einfluss jedes Features auf eine spezifische Vorhersage zuzuordnen, was für regulatorische und Debugging-Szenarien entscheidend ist.
Ein Modell, das für Entscheidungen wie die Kreditgenehmigung verwendet wird, muss fair sein und darf geschützte demografische Gruppen nicht diskriminieren.
Verwenden Sie die Fairness-Bewertung des Responsible AI-Dashboards, um Fairness-Metriken (z. B. demografische Parität, equalized odds) über sensible Features hinweg zu analysieren. Wenden Sie bei gefundenen Ungleichheiten Milderungstechniken wie Schwellenwertanpassungen nach der Verarbeitung an.
Warum: Die Fairness-Bewertung liefert quantitative Beweise für das Verhalten eines Modells über verschiedene Gruppen hinweg. Milderungstechniken helfen, Verzerrungen zu korrigieren, um gerechte Ergebnisse zu gewährleisten.
Ein LLM muss Fragen auf der Grundlage spezifischer, privater Unternehmensdokumente beantworten, ohne Fakten zu halluzinieren.
Implementieren Sie ein Retrieval-Augmented Generation (RAG)-Muster. Verwenden Sie Azure AI Search, um einen Vektorindex der Dokumente zu erstellen. Zum Abfragezeitpunkt rufen Sie relevante Dokumentabschnitte ab und übergeben diese als Kontext im Prompt an das LLM.
Warum: RAG verankert die Antwort des LLM in faktischen, aktuellen Informationen, reduziert Halluzinationen erheblich und ermöglicht es, Wissen zu nutzen, das nicht in seinen ursprünglichen Trainingsdaten enthalten ist.
Ein LLM muss konsistent spezifische Richtlinien, Ton und Ausgabeformate (z. B. JSON generieren) befolgen.
Verwenden Sie detailliertes System-Prompt-Engineering. Geben Sie eine klare Persona, explizite Regeln und Einschränkungen sowie Few-Shot-Beispiele für gewünschte Eingabe-/Ausgabe-Paare an.
Warum: Ein gut ausgearbeiteter System-Prompt ist die direkteste und effektivste Methode, das Verhalten eines LLM zu steuern, ohne die Kosten und die Komplexität des Fine-Tunings.
Die Qualität einer RAG-basierten LLM-Anwendung muss gemessen werden.
Verwenden Sie RAG-spezifische Bewertungsmetriken wie Groundedness (wird die Antwort durch den Kontext gestützt?) und Relevance (beantwortet die Antwort die Frage des Benutzers?).
Warum: Standard-NLP-Metriken wie ROUGE sind unzureichend. Groundedness und Relevance messen direkt die Kernherausforderungen von RAG: Halluzinationen verhindern und nützliche Antworten liefern.
Eine LLM-Anwendung ist zu langsam oder zu teuer für den Produktionseinsatz.
Implementieren Sie einen Router, um kleinere, günstigere Modelle (z. B. GPT-3.5-Turbo) für einfache Aufgaben zu verwenden. Aktivieren Sie das Antwort-Caching für wiederholte Abfragen. Optimieren Sie die Prompt-Länge.
Warum: Die Verwendung des passenden Modells für die jeweilige Aufgabe ist die effektivste Maßnahme zur Kosteneinsparung. Caching eliminiert redundante API-Aufrufe und reduziert direkt Kosten und Latenz.
Eine LLM-Anwendung verarbeitet sensible Daten, die das Unternehmensnetzwerk nicht verlassen oder für das Modelltraining verwendet werden dürfen.
Stellen Sie den Azure OpenAI-Dienst mit einem privaten Endpunkt bereit. Konfigurieren Sie die Ressource so, dass keine Prompt-/Completion-Daten protokolliert werden.
Warum: Private Endpunkte gewährleisten die Netzwerkisolation. Die Option zum Nicht-Protokollieren bietet eine zusätzliche Ebene des Datenschutzes und erfüllt strenge Compliance-Anforderungen.
Ein in Azure AI Studio entwickelter Prompt Flow muss als hochverfügbarer, skalierbarer Produktionsendpunkt bereitgestellt werden.
Stellen Sie den Prompt Flow als Azure ML Managed Online Endpoint bereit.
Warum: Dies bietet einen nahtlosen Pfad von der Entwicklung zur Produktion und nutzt dieselbe robuste Infrastruktur (Auto-Skalierung, Lastverteilung, Überwachung), die auch für traditionelle ML-Modelle verwendet wird.
Eine benutzerseitige generative KI-Anwendung muss vor der Generierung oder Verarbeitung schädlicher, beleidigender oder unsicherer Inhalte geschützt werden.
Verwenden Sie sowohl die integrierten Azure OpenAI-Inhaltsfilter als auch den Azure AI Content Safety-Dienst für eine umfassende Moderation von Prompts und Completions.
Warum: Geschichtete Sicherheit ist entscheidend. Die integrierten Filter bieten eine Basis, während der dedizierte Content Safety-Dienst eine granularere Kontrolle und multimodale Fähigkeiten bietet.
Ein konversationeller KI-Chatbot muss den Kontext über mehrere Benutzerbeiträge hinweg aufrechterhalten.
LLMs sind zustandslos. Die Anwendung muss den Konversationsverlauf (z. B. in einer Sitzung oder Datenbank) verwalten und relevante Teile des Verlaufs in jeden neuen Prompt an das LLM aufnehmen.
Warum: Das explizite Bereitstellen von Kontext in jedem API-Aufruf ist die einzige Möglichkeit für ein zustandsloses LLM, sich an die Konversation zu "erinnern".
Es müssen verschiedene Prompts systematisch getestet werden, um denjenigen zu finden, der die beste LLM-Leistung erzielt.
Verwenden Sie Prompt Flow-Varianten. Definieren Sie mehrere Prompt-Versionen für einen Knoten und führen Sie einen Massentest gegen einen Bewertungsdatensatz durch, um Leistungsmetriken zu vergleichen.
Warum: Varianten bieten einen strukturierten, datengesteuerten Ansatz für Prompt Engineering, der über manuelles Trial-and-Error hinausgeht und eine systematische Optimierung ermöglicht.
Eine Produktions-LLM-Anwendung muss sowohl auf den operativen Zustand als auch auf die Antwortqualität überwacht werden.
Kombinieren Sie Application Insights für operationelle Telemetriedaten (Latenz, Fehlerraten, Token-Nutzung) mit periodischen Batch-Evaluierungsjobs unter Verwendung eines Evaluierungsflows, um die Antwortqualität (Groundedness, Relevanz) zu bewerten.
Warum: Die Überwachung von LLMs erfordert die Verfolgung sowohl der Systemleistung als auch der Qualität der generierten Inhalte. Diese Kombination bietet eine ganzheitliche Sicht auf die Anwendungsgesundheit.
