Freigeben über

Azure Machine Learning-Modellüberwachung

  • Artikel

Das Überwachen von Modellen ist der letzte Schritt im End-to-End-Lebenszyklus des maschinellen Lernens. Dieser Schritt verfolgt die Modellleistung in der Produktion nach und analysiert die Leistung sowohl aus Data Science-Sicht als auch aus operativer Sicht. In diesem Artikel erfahren Sie mehr über die Modellüberwachung in Azure Machine Learning, die Signale und Metriken, die Sie überwachen können, und empfohlene Methoden für die Modellüberwachung.

Im Gegensatz zu herkömmlichen Softwaresystemen hängt das Verhalten des Machine-Learning-Systems nicht nur von Regeln ab, die im Code angegeben sind, sondern wird auch anhand von Daten gelernt. Datenverteilungsänderungen, Abweichungen bei der Trainingsbereitstellung, Probleme mit der Datenqualität und Änderungen an Umgebungen oder am Verbraucherverhalten können dazu führen, dass ein Modell veraltet.

Wenn ein Modell veraltet, kann die Leistung zu dem Zeitpunkt, hat es möglicherweise keinen geschäftlichen Nutzen mehr oder verursacht schwerwiegende Complianceprobleme in stark regulierten Umgebungen. Daher ist es wichtig, die Modellleistung zu überwachen.

Funktionsweise der Azure Machine Learning-Modellüberwachung

Azure Machine Learning erfasst Überwachungssignale, indem statistische Berechnungen für gestreamte Produktionsrückschlussdaten und Referenzdaten durchgeführt werden. Produktionsrückschlussdten beziehen sich auf die in der Produktion gesammelten Eingabe- und Ausgabedaten des Modells. Die Referenzdaten können verlaufsbezogene Trainings-, Validierungs- oder Ground-Truth-Daten sein.

Wichtig

Die Azure Machine Learning-Modellüberwachung unterstützt nur die auf Anmeldeinformationen basierende Authentifizierung wie SAS-Token (Shared Access Signature) für den Zugriff auf in Datenspeichern enthaltene Daten. Weitere Informationen zu Datenspeichern und Authentifizierungsmodi finden Sie unter Datenverwaltung.

Jedes Überwachungssignal verfügt über eine oder mehrere Metriken. Sie können Schwellenwerte für diese Metriken festlegen, um Warnungen zu Modell- oder Datenanomalien über Azure Machine Learning oder Azure Event Grid zu erhalten. Wenn Sie Warnungen erhalten, können Sie zur Analyse oder Problembehandlung von Überwachungssignalen Azure Machine Learning Studio verwenden, um die Modellqualität kontinuierlich zu verbessern.

Azure Machine Learning verwendet den folgenden Prozess zum Verarbeiten eines integrierten Überwachungssignals, z. B. Datendrift, für ein Modell in der Produktion:

  • Zunächst berechnet Azure Machine Learning die statistische Verteilung des Werts des Features in den Trainingsdaten. Diese Verteilung ist die Baselineverteilung für das Feature.

  • Als Nächstes berechnet Azure Machine Learning die statistische Verteilung der neuesten Werte des Features, die in der Produktion aufgezeichnet wurden.

  • Azure Machine Learning führt dann einen statistischen Test durch oder berechnet eine Divergenz, um die Verteilung der neuesten Werte des Features in der Produktion mit der Baselineverteilung zu vergleichen. Wenn die Teststatistik oder der Divergenz-Score zwischen den beiden Verteilungen einen vom Benutzenden angegebenen Schwellenwert überschreitet, identifiziert Azure Machine Learning die Anomalie und benachrichtigt den Benutzenden.

Einrichten und Verwenden der Modellüberwachung

So verwenden Sie die Modellüberwachung in Azure Machine Learning

Aktivieren Sie zunächst die Sammlung von Produktionsrückschlussdaten.

  • Wenn Sie ein Modell an einem Azure Machine Learning-Onlineendpunkt bereitstellen, können Sie die Sammlung von Produktionsrückschlussdaten mithilfe der Azure Machine Learning-Modelldatensammlung aktivieren.
  • Wenn Sie ein Modell außerhalb von Azure Machine Learning oder auf einem Azure Machine Learning-Batchendpunkt bereitstellen, sind Sie für das Sammeln von Produktionsrückschlussdaten verantwortlich, die Sie anschließend für die Azure Machine Learning-Modellüberwachung verwenden können.

Richten Sie als Nächstes die Modellüberwachung ein. Sie können das Azure Machine Learning SDK, die CLI 2.0 oder die Studio-Benutzeroberfläche verwenden, um die Modellüberwachung unkompliziert einzurichten. Während des Setups können Sie Ihre bevorzugten Überwachungssignale angeben und Metriken und Schwellenwerte für jedes Signal anpassen.

Zeigen Sie schließlich die Ergebnisse der Modellüberwachung an, und analysieren Sie sie. Nachdem Sie die Modellüberwachung eingerichtet haben, führt Azure Machine Learning einen Überwachungsauftrag in Ihrem angegebenen Zeitplan aus. Jede Ausführung berechnet und wertet Metriken für alle ausgewählten Überwachungssignale aus und löst Warnungsbenachrichtigungen aus, wenn ein festgelegter Schwellenwert überschritten wird. Sie können dem Link in der Warnungsbenachrichtigung folgen, um Überwachungsergebnisse in Ihrem Azure Machine Learning-Arbeitsbereich anzuzeigen und zu analysieren.

Funktionen der Modellüberwachung

Azure Machine Learning bietet die folgenden Funktionen für die kontinuierliche Modellüberwachung:

  • Integrierte Überwachungssignale für Tabellendaten umfassen Datendrift, Vorhersagedrift, Datenqualität, Featurezuordnungsdrift und Modellleistung.
  • Sofort einsatzbereite Modellüberwachung für Onlineendpunkte. Wenn Sie Ihr Modell in der Produktion in einem Onlineendpunkt bereitstellen, erfasst Azure Machine Learning automatisch Produktionsrückschlussdaten und verwendet sie für die kontinuierliche Überwachung.
  • Mehrere Überwachungssignale in einem Überwachungssetup. Für jedes Überwachungssignal können Sie Ihre bevorzugten Metriken und Warnungsschwellenwerte auswählen.
  • Auswahl von Referenzdaten für den Vergleich. Für Überwachungsignale können Sie Referenzdaten aus Trainingsdaten oder Produktionsdaten der jüngsten Vergangenheit festlegen.
  • Wichtigste N-Features für die Überwachung von Datendrift oder Datenqualität. Wenn Sie Trainingsdaten als Referenzdaten verwenden, können Sie Datendrift- oder Datenqualitätssignale definieren, die die Featurerelevanz überlagern.
  • Möglichkeit zum Definieren benutzerdefinierter Überwachungssignale. Wenn die integrierten Überwachungssignale nicht für Ihr Geschäftsszenario geeignet sind, können Sie Ihr eigenes Überwachungssignal mit einer benutzerdefinierten Überwachungssignalkomponente definieren.
  • Flexibilität bei der Verwendung von Produktionsrückschlussdaten aus einer beliebigen Quelle. Wenn Sie Modelle außerhalb von Azure Machine Learning oder Modelle für Batchendpunkte bereitstellen, können Sie weiterhin selbst Produktionsrückschlussdaten sammeln und diese bei der Azure Machine Learning-Modellüberwachung verwenden.

Bewährte Methoden für die Modellüberwachung

Jedes Machine Learning-Modell und seine Anwendungsfälle sind einzigartig. Daher ist auch die Modellüberwachung für jede Situation einzigartig. In der folgenden Liste werden empfohlene bewährte Methoden für die Modellüberwachung beschrieben.

  • Beginnen Sie mit der Modellüberwachung unmittelbar nach der Bereitstellung eines Modells in der Produktion.
  • Arbeiten Sie mit Data Scientists zusammen, die mit dem Modell vertraut sind, um die Überwachung einzurichten. Data Scientists, die Erkenntnisse über das Modell und seine Anwendungsfälle haben, können Überwachungssignale und Metriken empfehlen und die richtigen Warnungsschwellenwerte für jede Metrik festlegen, um überzählige Warnungen zu verhindern.
  • Nehmen Sie mehrere Überwachungssignale in Ihr Setup auf. Mit mehreren Überwachungssignalen erhalten Sie sowohl umfassende als auch präzise Überwachungsansichten. Beispielsweise können Sie Signale für Datendrift und Featurezuordnungsdrift kombinieren, um eine frühzeitige Warnung zu Problemen mit der Modellleistung zu erhalten.
  • Verwenden Sie geeignete Referenzdaten als Vergleichsbaseline. Für Referenzdaten, die als Vergleichsbaseline verwendet werden, können Sie Produktionsdaten der jüngsten Vergangenheit oder historische Daten (z. B. Trainingsdaten oder Validierungsdaten) verwenden. Verwenden Sie für einen aussagekräftigeren Vergleich Trainingsdaten als Vergleichsbaseline für Datendrift und Datenqualität. Verwenden Sie für Vorhersagedrift Validierungsdaten als Vergleichsbaseline.
  • Angeben der Überwachungshäufigkeit basierend auf der Zunahme der Produktionsdaten im Laufe der Zeit. Wenn Ihr Produktionsmodell beispielsweise täglich viel Datenverkehr aufweist und die tägliche Datenakkumulation ausreichend groß ist, legen Sie die Überwachungshäufigkeit auf täglich fest. Andernfalls können Sie eine wöchentliche oder monatliche Überwachungshäufigkeit basierend auf dem Wachstum Ihrer Produktionsdaten im Laufe der Zeit in Betracht ziehen.
  • Überwachen der wichtigsten N-Features oder einer Featureteilmenge. Wenn Sie Trainingsdaten als die Vergleichsbaseline verwenden, können Sie die Datendrift- oder die Datenqualitätsüberwachung ganz einfach für die wichtigsten Top-N-Features konfigurieren. Bei Modellen mit einer großen Anzahl von Features sollten Sie eine Teilmenge dieser Features überwachen, um die Berechnungskosten und das Überwachungsrauschen zu reduzieren.
  • Verwenden Sie das Modellleistungssignal, wenn Sie Zugriff auf Ground-Truth-Daten haben. Wenn Sie Zugriff auf Ground-Truth-Daten (auch als Ist-Daten bezeichnet) haben, die auf Ihrer Machine Learning-Anwendung basieren, verwenden Sie das Modellleistungssignal, um die Grundwahrheitsdaten mit der Modellausgabe zu vergleichen. Dieser Vergleich bietet einen objektiven Einblick in die Modellleistung in der Produktion.

Größe und Offset des Lookbackfensters

Die Größe des Rückblickfensters ist die Zeitdauer im ISO 8601-Format für das Produktions- oder Referenzdatenfenster. Der Rückblickfensteroffset ist die Offsetdauer für das Ende Ihres Datenfensters, ausgehend vom Datum der Überwachungsausführung.

Ihr Modell in der Produktion verfügt beispielsweise über einen Monitor, der am 31. Januar um 15:15 Uhr UTC ausgeführt werden soll. Eine Größe von P7D oder sieben Tagen des Rückblickfensters für Produktionsdaten und ein Daten-Rückblickfensteroffset von P0D oder null Tagen bedeutet, dass der Monitor Produktionsdaten vom 24. Januar um 15:15 Uhr UTC bis zum 31. Januar um 15:15 Uhr UTC verwendet, d. h. die Zeit, zu der Ihr Monitor ausgeführt wird.

Wenn Sie für die Referenzdaten den Rückblickfensteroffset auf P7D oder sieben Tage festlegen, endet das Referenzdatenfenster direkt vor dem Start des Produktionsdatenfensters, sodass keine Überlappung vorhanden ist. Anschließend können Sie die Lookbackfenstergröße für Referenzdaten so groß wie möglich festlegen.

Wenn Sie beispielsweise die Größe des Rückblickfensters für Referenzdaten auf P24D oder 24 Tage festlegen, enthält das Referenzdatenfenster Daten vom 1. Januar um 15:15 Uhr UTC bis zum 24. Januar um 15:15 Uhr UTC. Das folgende Diagramm veranschaulicht dieses Beispiel:

Ein Diagramm, das die Größe des Lookbackfensters und den Offset für Referenz- und Produktionsdaten zeigt.

In einigen Fällen kann es hilfreich sein, den Rückblickfensteroffset für die Produktionsdaten auf eine Zahl festzulegen, die größer als null Tage ist. Wenn Ihr Monitor beispielsweise für die wöchentliche Ausführung immer montags um 15:15 Uhr UTC geplant ist, Sie aber keine Daten vom Wochenende in Ihrer Überwachungsausführung verwenden möchten, können Sie eine Rückblickfenstergröße von P5D oder fünf Tagen und einen Rückblickfensteroffset von P2D oder zwei Tagen verwenden. Ihr Datenfenster beginnt dann am letzten Montag um 15:15 Uhr UTC und endet am Freitag um 15:15 Uhr UTC.

In der Praxis sollten Sie sicherstellen, dass sich das Referenzdatenfenster und das Produktionsdatenfenster nicht überlappen. Wie in der folgenden Abbildung dargestellt, können Sie vermeiden, dass sich Fenster überlappen, indem Sie sicherstellen, dass der Offset des Rückblickfensters für Referenzdaten (P10D oder 10 Tage in diesem Beispiel) größer oder gleich der Summe der Rückblickfenstergröße der Produktionsdaten und des Offsets des Rückblickfensters (insgesamt sieben Tage in diesem Beispiel) ist.

Ein Diagramm mit nicht überlappenden Fenstern für Referenzdaten und Produktionsdaten.

Mit der Azure Machine Learning-Modellüberwachung können Sie intelligente Standardwerte für die Größe und den Offset des Lookbackfensters verwenden oder diese an Ihre Anforderungen anpassen. Sowohl rollierende Fenster als auch feste Fenster werden unterstützt.

Anpassen der Größe des Lookbackfensters

Sie können die Lookbackfenstergröße sowohl für die Produktionsdaten als auch für die Referenzdaten flexibel auswählen.

  • Standardmäßig ist die Lookbackfenstergröße für Produktionsdaten Ihre Überwachungsfrequenz. Alle Daten, die im Überwachungszeitraum vor der Ausführung des Überwachungsauftrags gesammelt wurden, sind im Rückblickfenster enthalten. Sie können die production_data.data_window.lookback_window_size-Eigenschaft verwenden, um das rollierende Datenfenster für Produktionsdaten anzupassen.

  • Standardmäßig ist das Lookbackfenster für die Referenzdaten das vollständige Dataset. Mit der reference_data.data_window.lookback_window_size-Eigenschaft können Sie die Größe des Referenzlookbackfensters anpassen.

Um ein festes Datenfenster für die Referenzdaten anzugeben, verwenden Sie die Eigenschaften reference_data.data_window.window_start_date und reference_data.data_window.window_end_date.

Anpassen des Offsets des Lookbackfensters

Sie können den Lookbackfensteroffset für Ihr Datenfenster sowohl für die Produktionsdaten als auch für die Referenzdaten flexibel auswählen. Sie können den Offset für die präzise Kontrolle über die von Ihrem Monitor verwendeten Daten verwenden. Der Offset gilt nur für die rollierenden Datenfenster.

  • Standardmäßig ist der Offset für Produktionsdaten P0D null Tage. Sie können diesen Offset mit der Eigenschaft production_data.data_window.lookback_window_offset ändern.

  • Der Offset für Referenzdaten ist standardmäßig doppelt so viel wie production_data.data_window.lookback_window_size. Diese Einstellung stellt sicher, dass genügend Referenzdaten für statistisch aussagekräftige Überwachungsergebnisse vorhanden sind. Sie können diesen Offset mit der Eigenschaft reference_data.data_window.lookback_window_offset ändern.

Überwachen von Signalen und Metriken

Die Azure Machine Learning-Modellüberwachung unterstützt die folgenden Überwachungssignale und -metriken.

Wichtig

Die in diesem Artikel markierten Elemente (Vorschau) sind aktuell als öffentliche Vorschau verfügbar. Die Vorschauversion wird ohne Vereinbarung zum Servicelevel bereitgestellt und ist nicht für Produktionsworkloads vorgesehen. Manche Features werden möglicherweise nicht unterstützt oder sind nur eingeschränkt verwendbar. Weitere Informationen finden Sie unter Zusätzliche Nutzungsbestimmungen für Microsoft Azure-Vorschauen.

Überwachungssignal BESCHREIBUNG Metriken Modellaufgaben oder unterstütztes Datenformat Produktionsdaten Referenzdaten
Datendrift Verfolgt Änderungen in der Verteilung der Eingabedaten eines Modells nach, indem die Verteilung mit den Trainingsdaten des Modells oder den Produktionsdaten der jüngsten Vergangenheit verglichen werden. Jensen-Shannon-Divergenz, Populationsstabilitätsindex, normalisierte Wasserstein-Divergenz, Kolmogorow-Smirnow-Test mit zwei Stichproben, Chi-Quadrat-Test nach Pearson Klassifizierung (tabellarische Daten), Regression (tabellarische Daten) Produktionsdaten: Modelleingaben Produktionsdaten der letzten Vergangenheit oder Trainingsdaten
Vorhersagedrift Verfolgt Veränderungen in der Verteilung der vorhergesagten Ausgaben eines Modells nach, indem die Verteilung mit Validierungsdaten, gekennzeichneten Testdaten oder Produktionsdaten der jüngsten Vergangenheit verglichen werden. Jensen-Shannon-Divergenz, Populationsstabilitätsindex, normalisierte Wasserstein-Divergenz, Tschebyschew-Norm. Kolmogorow-Smirnow-Test mit zwei Stichproben, Chi-Quadrat-Test nach Pearson Klassifizierung (tabellarische Daten), Regression (tabellarische Daten) Produktionsdaten: Modellausgaben Produktionsdaten der letzten Vergangenheit oder Validierungsdaten
Datenqualität Verfolgt die Datenintegrität der Modelleingaben nach, indem sie mit den Trainingsdaten des Modells oder den Produktionsdaten der jüngsten Vergangenheit verglichen wird. Die Datenqualitätsprüfungen umfassen die Überprüfung auf NULL-Werte, Typkonflikte oder Werte außerhalb der Grenzen. NULL-Wert-Rate, Datentypfehlerrate, Rate von Werten außerhalb der Grenzen Klassifizierung (tabellarische Daten), Regression (tabellarische Daten) Produktionsdaten: Modelleingaben Produktionsdaten der letzten Vergangenheit oder Trainingsdaten
Featurezuordnungsdrift (Vorschau) Basiert auf dem Beitrag von Features zu Vorhersagen, auch als Featurerelevanz bezeichnet. Der Featureabweichungsdrift verfolgt die Featurerelevanz während der Produktion durch Vergleich mit der Featurerelevanz während des Trainings. Normalisierter diskontierter kumulativer Gewinn Klassifizierung (tabellarische Daten), Regression (tabellarische Daten) Produktionsdaten: Modelleingaben und -ausgaben Trainingsdaten (erforderlich)
Modellleistung: Klassifizierung (Vorschau) Verfolgt die objektive Leistung der Ausgabe eines Modells in der Produktion nach, indem sie mit gesammelten Ground-Truth-Daten verglichen wird. Genauigkeit, Präzision und Abruf Klassifizierung (Tabellendaten) Produktionsdaten: Modellausgaben Ground-Truth-Daten (erforderlich)
Modellleistung: Regression (Vorschau) Verfolgt die objektive Leistung der Ausgabe eines Modells in der Produktion nach, indem sie mit gesammelten Ground-Truth-Daten verglichen wird. Mittlere absolute Abweichung (MAE), mittlere quadratische Abweichung (MQA) und mittlere quadratische Gesamtabweichung (RMSE) Regression (Tabellendaten) Produktionsdaten: Modellausgaben Ground-Truth-Daten (erforderlich)
Generative KI: Sicherheit und Qualität der generierten Inhalte (Vorschau) Bewertet generative KI-Anwendungen auf Sicherheit und Qualität mittels GPT-gestützter Metriken Fundiertheit, Relevanz, Geläufigkeit, Ähnlichkeit, Kohärenz Fragen und Antworten Vorlagen für Prompt, Abschluss, Kontext und Anmerkung N/V

Datenqualitätsmetriken

Das Datenqualitätsüberwachungssignal verfolgt die Integrität der Eingabedaten eines Modells nach, indem die folgenden drei Metriken berechnet werden:

  • NULL-Wert-Rate
  • Datentypfehlerrate
  • Out-of-Bounds-Rate

Die Azure Machine Learning-Modellüberwachung unterstützt eine Genauigkeit von bis zu 0,00001 für Berechnungen der NULL-Wert-Rate, der Datentypfehlerrate und der Out-of-Bounds-Rate.

NULL-Wert-Rate

Die NULL-Wert-Rate ist die Rate der NULL-Werte in der Modelleingabe für jedes Feature. Wenn das Überwachungsfenster für Produktionsdaten beispielsweise 100 Zeilen enthält und der Wert für das Feature temperature null für 10 dieser Zeilen ist, beträgt die NULL-Wert-Rate für temperature 10 %.

Azure Machine Learning unterstützt die Berechnung der NULL-Wert-Rate für alle Featuredatentypen.

Datentypfehlerrate

Während jeder Überwachungsausführung leitet die Azure Machine Learning-Modellüberwachung den Datentyp für jedes Feature aus den Referenzdaten ab. Die Datentypfehlerrate ist die Rate der Datentypunterschiede zwischen dem aktuellen Produktionsdatenfenster und den Referenzdaten.

Wenn beispielsweise der Datentyp für das Feature temperature aus den Referenzdaten als IntegerType abgeleitet wird, aber im Produktionsdatenfenster 10 von 100 Werten für temperature nicht IntegerType, sondern Zeichenfolgen sind, beträgt die Fehlerrate des Datentyps für temperature 10 %.

Azure Machine Learning unterstützt die Berechnung der Datentypfehlerrate für die folgenden Datentypen, die in PySpark verfügbar sind: ShortType, BooleanType, BinaryType, DoubleType, TimestampType, StringType, IntegerType, FloatType, ByteType, LongType und DateType. Wenn der Datentyp für ein Feature nicht in dieser Liste enthalten ist, wird die Azure Machine Learning-Modellüberwachung trotzdem ausgeführt, die Datentypfehlerrate für dieses Feature wird jedoch nicht berechnet.

Out-of-Bounds-Rate

Während jeder Überwachungsausführung bestimmt die Azure Machine Learning-Modellüberwachung den zulässigen Bereich oder die zulässige Menge für jedes Feature aus den Referenzdaten. Die Out-of-Bounds-Rate ist die Rate der Werte für jedes Feature, die außerhalb des zulässigen Bereichs oder der zulässigen Menge liegen, der bzw. die durch die Referenzdaten bestimmt wird.

  • Bei numerischen Features ist der entsprechende Bereich das numerische Intervall zwischen den Minimal- und Maximalwerten im Referenzdataset, z. B. [0, 100].
  • Bei einem kategorisierten Feature, z. B. color, ist der zulässige Bereich eine Menge aller Werte, die im Referenzdataset enthalten sind, z. B. [red, yellow, green].

Wenn beispielsweise das numerisches Feature temperature vorhanden ist, bei dem alle Werte im Referenzdataset im Bereich [37, 77] liegen, aber im Produktionsdatenfenster 10 von 100 Werten für temperature außerhalb des Bereichs [37, 77] liegen, dann beträgt die Out-of-Bounds-Rate für temperature 10 %.

Azure Machine Learning unterstützt die Berechnung der Out-of-Bounds-Rate für die folgenden Datentypen, die in PySpark verfügbar sind: StringType, IntegerType, DoubleType, ByteType, LongType und FloatType. Wenn der Datentyp für ein Feature nicht in dieser Liste enthalten ist, wird die Azure Machine Learning-Modellüberwachung trotzdem ausgeführt, die Out-of-Bounds-Rate für dieses Feature wird jedoch nicht berechnet.

Integration der Modellüberwachung mit Azure Event Grid

Sie können Ereignisse verwenden, die von Azure Machine Learning-Modellüberwachungsausführungen generiert werden, um ereignisgesteuerte Anwendungen, Prozesse oder CI/CD-Workflows (Continuous Integration und Continuous Delivery) mit Azure Event Grid einzurichten. Wenn Ihr Modellmonitor Abweichungs-, Datenqualitäts- oder Modellleistungsbeeinträchtigungen erkennt, können Sie diese Ereignisse mit Event Grid nachverfolgen und programmgesteuert Maßnahmen ergreifen.

Wenn beispielsweise die Genauigkeit Ihres Klassifizierungsmodells in der Produktion unter einen bestimmten Schwellenwert sinkt, können Sie mit Event Grid einen erneuten Trainingsauftrag starten, der gesammelte Ground-Truth-Daten verwendet. Informationen zum Integrieren von Azure Machine Learning in Event Grid finden Sie unter Überwachen der Leistung von Modellen, die in der Produktion bereitgestellt werden.

Zugehöriger Inhalt