KAPITEL 6

Entwurfsmuster für Reproduzierbarkeit

Software-Best-Practices wie zum Beispiel Unit-Tests gehen davon aus, dass ausgeführter Code eine deterministische Ausgabe liefert:

def sigmoid(x):

return 1.0 / (1 + np.exp(-x))

class TestSigmoid(unittest.TestCase):

def test_zero(self):

self.assertAlmostEqual(sigmoid(0), 0.5)

def test_neginf(self):

self.assertAlmostEqual(sigmoid(float("-inf")), 0)

def test_inf(self):

self.assertAlmostEqual(sigmoid(float("inf")), 1)

Beim maschinellen Lernen ist eine derartige Reproduzierbarkeit schwierig. Beim Training werden ML-Modelle mit Zufallswerten initialisiert und dann basierend auf den Trainingsdaten angepasst. Wenn Sie aber in dem von scikit-learn implementierten einfachen k-Means-Algorithmus random_state festlegen, liefert der Algorithmus jedes Mal die gleichen Ergebnisse:

def cluster_kmeans(X):

from sklearn import cluster

k_means = cluster.KMeans(n_clusters=10, random_state=10)

labels = k_means.fit(X).labels_[::]

return labels

Abgesehen vom zufälligen Startwert (Seed) müssen viele andere Artefakte festgelegt werden, um Reproduzierbarkeit beim Training sicherzustellen. Darüber hinaus besteht maschinelles Lernen aus verschiedenen Phasen wie zum Beispiel Training, Bereitstellung und Retraining. Oft ist es wichtig, dass manche Dinge auch über diese Phasen hinweg reproduzierbar sind.

Dieses Kapitel stellt Entwurfsmuster vor, die mit verschiedenen Aspekten der Reproduzierbarkeit zu tun haben. Das Entwurfsmuster Transformation erfasst Abhängigkeiten bei der Datenaufbereitung aus der Modell-Trainingspipeline, um sie beim Serving zu reproduzieren. Das Entwurfsmuster Wiederholbare Aufteilung befasst sich mit der Art und Weise, wie die Daten zwischen Trainings-, Validierungs- und Testdatensätzen aufzuteilen sind, damit ein im Training verwendetes Beispiel niemals für die Bewertung oder das Testen herangezogen wird, selbst wenn der Datensatz wächst. Beim Entwurfsmuster Bridged Schema geht es darum, wie sich Reproduzierbarkeit sicherstellen lässt, wenn der Trainingsdatensatz eine Mischung von Daten ist, die verschiedenen Schemas entsprechen. Das Entwurfsmuster Workflow-Pipeline erfasst alle Schritte im ML-Prozess, um sicherzustellen, dass beim Retraining des Modells Teile der Pipeline wiederverwendet werden können. Beim Entwurfsmuster Feature Store dreht sich alles um Reproduzierbarkeit und Wiederverwendbarkeit von Features über verschiedene ML-Jobs hinweg. Das Entwurfsmuster Windowed Inference stellt sicher, dass sich Features, die dynamisch und zeitabhängig berechnet werden, zwischen Training und Serving korrekt wiederholen lassen. Die Versionierung von Daten und Modellen ist eine Voraussetzung für den Umgang mit vielen der in diesem Kapitel beschriebenen Entwurfsmuster.

Entwurfsmuster 21: Transformation

Das Entwurfsmuster Transformation erleichtert es, ein ML-Modell in die Produktion zu überführen, indem Eingaben, Features und Transformationen sorgfältig getrennt bleiben.

Problem

Das Problem ist, dass die Eingaben in ein ML-Modell nicht die Features sind, die das ML-Modell bei seinen Berechnungen verwendet. Zum Beispiel sind die Eingaben in einem Textklassifizierungsmodell die rohen Textdokumente, und die Features sind die numerischen Darstellungen dieses Texts in der Einbettung. Wenn wir ein ML-Modell trainieren, dann trainieren wir es mit Features, die aus den rohen Eingaben extrahiert werden. Wir nehmen hier dieses Modell, das mit BigQuery ML dafür trainiert wurde, die Dauer von Fahrradtouren in London vorherzusagen:

CREATE OR REPLACE MODEL ch09eu.bicycle_model

OPTIONS(input_label_cols=['duration'],

model_type='linear_reg')

SELECT

duration

, start_station_name

, CAST(EXTRACT(dayofweek from start_date) AS STRING)

as dayofweek

, CAST(EXTRACT(hour from start_date) AS STRING)

as hourofday

FROM

`bigquery-public-data.london_bicycles.cycle_hire`

Dieses Modell hat drei Features (start_station_name, dayofweek und hourofday), die aus zwei Eingaben (start_station_name und start_date) berechnet werden, wie Abbildung 6-1 zeigt.

Abbildung 6-1: Das Modell umfasst drei Features, die aus zwei Eingaben berechnet werden.

Der obige SQL-Code mischt aber die Eingaben und Features, ohne dabei die ausgeführten Transformationen zu verfolgen. Das macht sich bemerkbar, wenn wir versuchen, mit diesem Modell Vorhersagen zu treffen. Da das Modell auf drei Features trainiert wurde, muss die Vorhersagesignatur wie folgt aussehen:

SELECT * FROM ML.PREDICT(MODEL ch09eu.bicycle_model,(

'Kings Cross' AS start_station_name

, '3' as dayofweek

, '18' as hourofday

))

Zur Inferenzzeit müssen wir wissen, auf welchen Features das Modell trainiert wurde, wie sie interpretiert werden sollen und wie die angewandten Transformationen im Detail aussehen – zum Beispiel, dass wir '3' für den Wochentag (dayofweek) einzugeben haben. Was bedeutet diese '3'? Dienstag oder Mittwoch? Das hängt davon ab, welche Bibliothek das Modell verwendet oder welchen Tag wir als Wochenanfang betrachten!

Die Verzerrungen zwischen Training und Serving, die aus Unterschieden bei diesen Faktoren zwischen Trainings- und Serving-Umgebungen resultieren, ist einer der Hauptgründe, warum es so schwierig ist, ML-Modelle in produktionsreife Versionen zu überführen.

Lösung

Die Lösung besteht darin, die zum Konvertieren der Modelleingaben in Features angewandten Transformationen explizit zu erfassen. In BigQuery ML erledigen Sie dies mit der TRANSFORM-Klausel. Damit stellen Sie sicher, dass die Transformationen automatisch während ML.PREDICT angewendet werden.

Mit der Unterstützung für TRANSFORM sollte das obige Modell wie folgt umgeschrieben werden:

CREATE OR REPLACE MODEL ch09eu.bicycle_model

OPTIONS(input_label_cols=['duration'],

model_type='linear_reg')

TRANSFORM(

SELECT * EXCEPT(start_date)

, CAST(EXTRACT(dayofweek from start_date) AS STRING)

as dayofweek -- feature1

, CAST(EXTRACT(hour from start_date) AS STRING)

as hourofday –- feature2

)

SELECT

duration, start_station_name, start_date -- Eingaben

FROM

`bigquery-public-data.london_bicycles.cycle_hire`

Die Eingaben (in der SELECT-Klausel) haben wir jetzt klar von den Features (in der TRANSFORM-Klausel) getrennt. Die Vorhersage ist jetzt viel einfacher. Wir brauchen lediglich den Stationsnamen und einen Zeitstempel (die Eingaben) an das Modell zu senden:

SELECT * FROM ML.PREDICT(MODEL ch09eu.bicycle_model,(

'Kings Cross' AS start_station_name

, CURRENT_TIMESTAMP() as start_date

))

Das Modell kümmert sich dann darum, die entsprechenden Transformationen durchzuführen, um die erforderlichen Features zu erzeugen. Dazu erfasst es sowohl die Transformationslogik als auch die Artefakte (wie zum Beispiel Skalierungskonstanten, Einbettungskoeffizienten, Nachschlagetabellen usw.), die für die Transformation benötigt werden.

Solange wir genau darauf achten, in der SELECT-Anweisung nur die Roheingaben zu verwenden und die gesamte darauffolgende Verarbeitung der Eingabe in der TRANSFORM-Klausel unterzubringen, wendet BigQuery ML diese Transformationen während der Vorhersage automatisch an.

Kompromisse und Alternativen

Die oben beschriebene Lösung funktioniert, weil BigQuery ML die Transformationslogik und Artefakte für uns verfolgt, sie im Modellgraphen speichert und die Transformationen während der Vorhersage automatisch anwendet.

Wenn wir ein Framework verwenden, das das Entwurfsmuster Transformation von Haus aus nicht unterstützt, sollten wir unsere Modellarchitektur so entwerfen, dass sich die während des Trainings durchgeführten Transformationen während des Servings leicht reproduzieren lassen. Wir erreichen das, indem wir die Transformationen im Modellgraphen speichern oder ein Repository von transformierten Features erstellen (siehe »Entwurfsmuster 26: Feature Store« auf Seite 325).

Transformationen in TensorFlow und Keras

Nehmen wir an, wir trainierten ein ML-Modell mit sechs Eingaben (Breitengrad beim Zusteigen, Längengrad beim Zusteigen, Breitengrad beim Aussteigen, Längengrad beim Aussteigen, Anzahl der Mitfahrer und Zeit des Zusteigens), um den Taxitarif in New York zu schätzen. TensorFlow unterstützt das Konzept der Feature-Spalten, die im Modellgraphen gespeichert werden. Allerdings geht die API konzeptionell davon aus, dass die Roheingaben die gleichen sind wie die Features.

Wenn wir zum Beispiel die Breiten- und Längengrade skalieren wollen (Details hierzu siehe »Einfache Datendarstellungen« auf Seite 40 in Kapitel 2), erstellen wir ein transformiertes Feature, das den euklidischen Abstand darstellt, und extrahieren die Stunde des Tages aus dem Zeitstempel. Den Modellgraphen (siehe Abbildung 6-2) müssen wir sorgfältig entwerfen und dabei das Transformation-Konzept im Hinterkopf behalten. Beachten Sie im unten erläuterten Code, wie wir drei separate Schichten in unserem Keras-Modell entwerfen – die Eingabeschicht, die Transformationsschicht und eine DenseFeatures-Schicht.

Abbildung 6-2: Der Modellgraph für das Problem der Taxitarifschätzung in Keras

Machen Sie zunächst jede Eingabe in das Keras-Modell zu einer Input-Schicht (den vollständigen Code finden Sie auf GitHub in einem Notebook unter https://github.com/GoogleCloudPlatform/training-data-analyst/blob/master/quests/serverlessml/06_feateng_keras/solution/taxifare_fc.ipynb):

inputs = {

colname : tf.keras.layers.Input(

name=colname, shape=(), dtype='float32')

for colname in ['pickup_longitude', 'pickup_latitude',

'dropoff_longitude', 'dropoff_latitude']

}

In Abbildung 6-2 sind die Kästen mit dropoff_latitude, dropoff_longitude usw. gekennzeichnet.

Als Zweites verwalten Sie ein Dictionary der transformierten Features und machen jede Transformation entweder zu einer Keras-Vorverarbeitungsschicht oder zu einer Lambda-Schicht. Hier skalieren wir die Eingaben mithilfe von Lambda-Schichten:

transformed = {}

for lon_col in ['pickup_longitude', 'dropoff_longitude']:

transformed[lon_col] = tf.keras.layers.Lambda(

lambda x: (x+78)/8.0,

name='scale_{}'.format(lon_col)

)(inputs[lon_col])

for lat_col in ['pickup_latitude', 'dropoff_latitude']:

transformed[lat_col] = tf.keras.layers.Lambda(

lambda x: (x-37)/8.0,

name='scale_{}'.format(lat_col)

)(inputs[lat_col])

In Abbildung 6-2 sind dies die Kästen, die mit scale_dropoff_latitude, scale_dropoff_longitude usw. gekennzeichnet sind.

Außerdem richten wir eine Lambda-Schicht für den euklidischen Abstand ein, der aus vier der Input-Schichten berechnet wird (siehe Abbildung 6-2):

def euclidean(params):

lon1, lat1, lon2, lat2 = params

londiff = lon2 - lon1

latdiff = lat2 - lat1

return tf.sqrt(londiff*londiff + latdiff*latdiff)

transformed['euclidean'] = tf.keras.layers.Lambda(euclidean, name='euclidean')([

inputs['pickup_longitude'],

inputs['pickup_latitude'],

inputs['dropoff_longitude'],

inputs['dropoff_latitude']

])

Ebenso ist die Spalte, in der die Stunde des Tages aus dem Zeitstempel gespeichert wird, eine Lambda-Schicht:

transformed['hourofday'] = tf.keras.layers.Lambda(

lambda x: tf.strings.to_number(tf.strings.substr(x, 11, 2),

out_type=tf.dtypes.int32),

name='hourofday'

)(inputs['pickup_datetime'])

Drittens werden alle diese transformierten Schichten zu einer DenseFeatures-Schicht verkettet:

dnn_inputs = tf.keras.layers.DenseFeatures(feature_columns.values())(transformed)

Da der Konstruktor für DenseFeatures einen Satz von Feature-Spalten benötigt, müssen wir angeben, wie die einzelnen transformierten Werte zu übernehmen sind, und sie in eine Eingabe für das neuronale Netz konvertieren. Wir können sie so verwenden, wie sie sind, 1-aus-n-codieren oder die Zahlen partitionieren. Der Einfachheit halber verwenden wir sie einfach alle so, wie sie sind:

feature_columns = {

colname: tf.feature_column.numeric_column(colname)

for colname in ['pickup_longitude', 'pickup_latitude',

'dropoff_longitude', 'dropoff_latitude']

}

feature_columns['euclidean'] = \

tf.feature_column.numeric_column('euclidean')

Nachdem wir eine DenseFeatures-Eingabeschicht haben, können wir den Rest des Keras-Modells wie gewohnt aufbauen:

h1 = tf.keras.layers.Dense(32, activation='relu', name='h1')(dnn_inputs)

h2 = tf.keras.layers.Dense(8, activation='relu', name='h2')(h1)

output = tf.keras.layers.Dense(1, name='fare')(h2)

model = tf.keras.models.Model(inputs, output)

model.compile(optimizer='adam', loss='mse', metrics=['mse'])

Das vollständige Beispiel finden Sie auf GitHub unter https://github.com/GoogleCloudPlatform/training-data-analyst/blob/master/quests/serverlessml/06_feateng_keras/solution/taxifare_fc.ipynb.

Die erste Schicht des Keras-Modells ist als inputs-Schicht eingerichtet. Die zweite Schicht ist die Transform-Schicht. Die DenseFeatures-Schicht als dritte Schicht kombiniert die ersten beiden Schichten. Nach dieser Folge von Schichten beginnt die übliche Modellarchitektur. Da die transform-Schicht Teil des Modellgraphen ist, funktionieren die üblichen Lösungen mit Serving-Funktion und Batch-Serving (siehe Kapitel 5) wie gehabt.

Effiziente Transformationen mit tf.transform

Nachteilig beim obigen Ansatz ist, dass die Transformationen bei jeder Iteration des Trainings durchgeführt werden. Das ist nicht tragisch, wenn wir lediglich mit bekannten Konstanten skalieren. Doch wie sieht es aus, wenn unsere Transformationen rechenintensiver sind? Was ist, wenn wir nach dem Mittelwert und der Varianz skalieren wollen, wobei wir zuerst sämtliche Daten durchlaufen müssen, um diese Variablen zu berechnen?

Es ist hilfreich, zu unterscheiden zwischen Transformationen auf Instanzebene, die direkt Teil des Modells sein können (wobei der einzige Nachteil darin besteht, sie bei jeder Trainingsiteration anzuwenden), und Transformationen auf Datensatzebene, bei denen wir einen vollständigen Durchlauf benötigen, um die Gesamtstatistiken oder das Vokabular einer kategorialen Variablen zu berechnen. Solche Transformationen auf Datensatzebene können nicht Teil des Modells sein und müssen als skalierbarer Vorverarbeitungsschritt angewendet werden, der die Transformation erzeugt und dabei die Logik und die Artefakte (Mittelwert, Varianz, Vokabular usw.) erfasst, die dem Modell zugeordnet werden. Für Transformationen auf Datensatzebene verwenden Sie tf.transform.

Die Bibliothek tf.transform (die Teil von TensorFlow Extended (https://oreil.ly/OznI3) ist) bietet eine effiziente Möglichkeit, Transformationen über einen Vorverarbeitungsdurchlauf durch die Daten durchzuführen und die resultierenden Features und Transformationsartefakte zu speichern, sodass sich die Transformationen durch TensorFlow Serving während der Vorhersagezeit anwenden lassen.

Der erste Schritt besteht darin, die Transformationsfunktion zu definieren. Um zum Beispiel alle Eingaben so zu skalieren, dass sich der Mittelwert null und die Einheitsvarianz ergeben, würden wir die folgende Vorverarbeitungsfunktion erstellen (den vollständigen Code finden Sie auf GitHub unter https://github.com/tensorflow/tfx/blob/master/tfx/examples/chicago_taxi_pipeline/taxi_utils_native_keras.py):

def preprocessing_fn(inputs):

outputs = {}

for key in ...:

outputs[key + '_z'] = tft.scale_to_z_score(inputs[key])

outputs[key + '_bkt'] = tft.bucketize(inputs[key], 5)

return outputs

Vor dem Training werden die Rohdaten in Apache Beam gelesen und mit der obigen Funktion transformiert:

transformed_dataset, transform_fn = (raw_dataset |

beam_impl.AnalyzeAndTransformDataset(preprocessing_fn))

transformed_data, transformed_metadata = transformed_dataset

Die transformierten Daten werden dann in einem Format ausgegeben, das für das Lesen durch die Trainingspipeline geeignet ist:

transformed_data | tfrecordio.WriteToTFRecord(

PATH_TO_TFT_ARTIFACTS,

coder=example_proto_coder.ExampleProtoCoder(

transformed_metadata.schema))

Die Beam-Pipeline speichert auch die Vorverarbeitungsfunktion, die ausgeführt werden muss, zusammen mit allen Artefakten, die die Funktion benötigt, in einem Artefakt im TensorFlow-Graph-Format. Zum Beispiel würde dieses Artefakt im obigen Fall den Mittelwert und die Varianz für die Skalierung der Zahlen und die Bucket-Grenzen für die Partitionierung der Zahlen enthalten. Die Trainingsfunktion liest transformierte Daten, und demzufolge müssen die Transformationen innerhalb der Trainingsschleife nicht wiederholt werden.

Die Serving-Funktion muss diese Artefakte laden und eine Transformationsschicht erstellen:

tf_transform_output = tft.TFTransformOutput(PATH_TO_TFT_ARTIFACTS)

tf_transform_layer = tf_transform_output.transform_features_layer()

Dann kann die Serving-Funktion die Transform-Schicht auf die geparsten Eingabe-Features anwenden und das Modell mit den transformierten Daten aufrufen, um die Modellausgabe zu berechnen:

@tf.function

def serve_tf_examples_fn(serialized_tf_examples):

feature_spec = tf_transform_output.raw_feature_spec()

feature_spec.pop(_LABEL_KEY)

parsed_features = tf.io.parse_example(serialized_tf_examples, feature_spec)

transformed_features = tf_transform_layer(parsed_features)

return model(transformed_features)

Auf diese Weise stellen wir sicher, dass die Transformationen für das Serving in den Modellgraphen eingefügt werden. Da das Modelltraining auf den transformierten Daten stattfindet, muss unsere Trainingsschleife diese Transformationen nicht während jeder Epoche durchführen.

Text- und Bildtransformationen

In Textmodellen ist es üblich, den Eingabetext aufzubereiten (unter anderem Satzzeichen, Stoppwörter, Großschreibung, Stemming usw. entfernen) und erst dann den bereinigten Text dem Modell als Feature bereitzustellen. Zum Feature Engineering für Texteingaben gehören auch die Tokenisierung und das Abgleichen mit regulären Ausdrücken. Wichtig ist, die gleichen Bereinigungs- oder Extraktionsschritte auch zur Inferenzzeit auszuführen.

Die Notwendigkeit, Transformationen zu erfassen, ist selbst dann wichtig, wenn es kein explizites Feature Engineering gibt, etwas beim Deep Learning mit Bildern. Bildmodelle besitzen in der Regel eine Eingabeschicht, die für Bilder einer bestimmten Größe ausgelegt ist. Bilder mit abweichenden Größen muss man beschneiden, auffüllen oder auf die feststehende Eingabegröße bringen, bevor sie in das Modell eingespeist werden. Andere gängige Transformationen in Bildmodellen sind Farbmanipulationen (Gammakorrektur, Graustufenumwandlung usw.) und Lagekorrekturen. Entscheidend ist, dass derartige Transformationen sowohl auf dem Trainingsdatensatz als auch während der Inferenzzeit identisch durchgeführt werden. Das Entwurfsmuster Transformation hilft, diese Reproduzierbarkeit sicherzustellen.

Bei Bildmodellen wendet man einige Transformationen (wie zum Beispiel Datenerweiterung durch zufälliges Cropping und Zoomen) nur während des Trainings an. Diese Transformationen müssen während der Inferenz nicht erfasst werden, und sie sind auch nicht Teil des Entwurfsmusters Transformation.

Alternative Musteransätze

Ein alternativer Ansatz, der das Problem der Verzerrung zwischen Training und Serving lösen soll, ist das Muster Feature Store. Es besteht aus einem koordinierten Berechnungsmodul und Repository von transformierten Feature-Daten. Das Berechnungsmodul unterstützt Zugriffe mit niedriger Latenz für die Inferenz und die Batch-Erstellung von transformierten Features, während das Daten-Repository schnellen Zugriff auf transformierte Features für das Modelltraining bietet. Ein Feature-Speicher hat den Vorteil, dass die Transformationsoperationen nicht in den Modellgraphen passen müssen. Wenn zum Beispiel der Feature-Speicher Java unterstützt, könnten Sie die Vorverarbeitungsoperationen in Java durchführen, während das Modell selbst in PyTorch geschrieben sein könnte. Der Nachteil eines Feature Store besteht darin, dass er das Modell vom Feature Store abhängig und die Serving-Infrastruktur wesentlich komplexer macht.

Die Programmiersprache und das für die Transformation der Features verwendete Framework kann man auch von der Sprache, mit der das Modell geschrieben wird, trennen, indem man die Vorverarbeitung in Containern durchführt und diese benutzerdefinierten Container sowohl als Teil des Trainings als auch des Servings verwendet. Auf dieses Verfahren, das auch in der Praxis von Kubeflow Serving übernommen wird, geht der Abschnitt »Entwurfsmuster 25: Workflow-Pipeline« auf Seite 312 ein.

Entwurfsmuster 22: Wiederholbare Aufteilung

Um wiederholbares und reproduzierbares Sampling sicherzustellen, ist es notwendig, eine gut verteilte Spalte und eine deterministische Hashfunktion zu verwenden, um die verfügbaren Daten in Trainings-, Validierungs- und Testdatensätze aufzuteilen.