Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Verarbeitung der aus Neptune zu Trainingszwecken exportierten Diagrammdaten Im Datenverarbeitungsschritt werden anhand der durch den Exportvorgang erstellten Neptune-Diagrammdaten die Informationen erstellt, die von der [Deep Graph Library (DGL](https://www.dgl.ai/)) beim Training verwendet werden. Dies umfasst die verschiedene Datenzuordnungen und -transformationen: + Analyse von Knoten und Kanten, um die von der DGL benötigten Diagramm- und ID-Zuordnungsdateien zu erstellen. + Konvertierung von Knoten- und Kanteneigenschaften in die von der DGL benötigten Knoten- und Kanten-Features. + Aufteilung der Daten in Trainings-, Validierungs- und Testsätze. ## Verwalten des Datenverarbeitungsschritts für Neptune ML Nach dem Export der Daten aus Neptune, die Sie für das Modelltraining verwenden möchten, können Sie einen Datenverarbeitungsauftrag mit einem `curl`-Befehl (oder `awscurl`-Befehl) wie dem folgenden starten: ``` curl \ -X POST https://(your Neptune endpoint)/ml/dataprocessing \ -H 'Content-Type: application/json' \ -d '{ "inputDataS3Location" : "s3://(Amazon S3 bucket name)/(path to your input folder)", "id" : "(a job ID for the new job)", "processedDataS3Location" : "s3://(S3 bucket name)/(path to your output folder)", "configFileName" : "training-job-configuration.json" }' ``` Details zur Verwendung dieses Befehls werden in [Der Datenverarbeitungsbefehl](machine-learning-api-dataprocessing.md) beschrieben. Dort finden Sie auch Informationen dazu, wie Sie ausgeführte Aufträge abrufen und beenden und alle ausgeführten Aufträge auflisten. ## Verarbeiten aktualisierter Diagrammdaten für Neptune ML Sie können der API auch eine `previousDataProcessingJobId` bereitstellen, damit der neue Datenverarbeitungsauftrag dieselbe Verarbeitungsmethode wie ein vorheriger Auftrag verwendet. Dies ist erforderlich, wenn Sie Vorhersagen für aktualisierte Diagrammdaten in Neptune erhalten möchten, indem Sie entweder das alte Modell mit den neuen Daten trainieren oder die Modellartefakte anhand der neuen Daten neu berechnen. Hierzu verwenden Sie einen `curl`-Befehl (oder`awscurl`-Befehl) wie diesen: ``` curl \ -X POST https://(your Neptune endpoint)/ml/dataprocessing \ -H 'Content-Type: application/json' \ -d '{ "inputDataS3Location" : "s3://(Amazon S3 bucket name)/(path to your input folder)", "id" : "(a job ID for the new job)", "processedDataS3Location" : "s3://(Amazon S3 bucket name)/(path to your output folder)", "previousDataProcessingJobId", "(the job ID of the previous data-processing job)"}' ``` Legen Sie den Wert des Parameters `previousDataProcessingJobId` auf die Auftrags-ID des vorherigen Datenverarbeitungsauftrags für das trainierte Modell fest. **Anmerkung** Das Löschen von Knoten im aktualisierten Diagramm wird zurzeit nicht unterstützt. Wenn in einem aktualisierten Diagramm Knoten entfernt wurden, müssen Sie einen völlig neuen Datenverarbeitungsauftrag starten, statt `previousDataProcessingJobId` zu verwenden. # Feature-Kodierung in Neptune ML Eigenschaftswerte haben verschiedene Formate und Datentypen. Um eine gute Machine-Learning-Leistung zu erzielen, müssen diese Werte in numerische Kodierungen konvertiert werden, so genannte *features*. Neptune ML extrahiert und kodiert Features im Rahmen der Schritte data-export und data-processing mit den hier beschrieben Feature-Kodierungs-Techniken. **Anmerkung** Wenn Sie eine eigene Feature-Kodierung in einer benutzerdefinierten Modellimplementierung implementieren möchten, können Sie die automatische Feature-Kodierung in der Datenvorverarbeitungsphase deaktivieren, indem Sie als Feature-Kodierungstyp `none` auswählen. In diesem Fall findet für diese Knoten- oder Kanteneigenschaft keine Feature-Kodierung statt. Stattdessen werden die rohen Eigenschaftswerte analysiert und in einem Verzeichnis gespeichert. Während der Datenvorverarbeitung wird weiter das DGL-Diagramm aus dem exportierten Datensatz erstellt, aber das konstruierte DGL-Diagramm verfügt nicht über keine vorverarbeiteten Features für das Training. Sie sollten diese Option nur verwenden, wenn Sie eine benutzerdefinierte Feature-Kodierung als Teil eines benutzerdefinierten Modelltrainings ausführen möchten. Details dazu finden Sie unter [Benutzerdefinierte Modelle in Neptune ML](machine-learning-custom-models.md). ## Kategorische Features in Neptune ML Eine Eigenschaft, die einen oder mehrere unterschiedliche Werte aus einer festen Liste möglicher Werte annehmen kann, ist ein kategorisches Feature. In Neptune ML werden kategorische Features mit [One-Hot-Kodierung](https://en.wikipedia.org/wiki/One-hot) kodiert. Das folgende Beispiel zeigt, wie die Eigenschaftsnamen verschiedener Lebensmittel entsprechend ihrer Kategorie mit One-Hot-Kodierung kodiert werden: ``` Food Veg. Meat Fruit Encoding --------- ---- ---- ----- -------- Apple 0 0 1 001 Chicken 0 1 0 010 Broccoli 1 0 0 100 ``` **Anmerkung** Die maximale Anzahl von Kategorien in einem kategorischen Feature ist 100. Wenn eine Eigenschaft mehr als 100 Wertkategorien besitzt, werden nur die 99 häufigsten Kategorien in verschiedenen Kategorien platziert. Der Rest wird in einer speziellen Kategorie mit dem Namen `OTHER` platziert. ## Numerische Features in Neptune ML Eine Eigenschaft, deren Werte reale Zahlen sind, kann in Neptune ML als numerisches Feature kodiert werden. Numerische Features werden mit Gleitkommazahlen kodiert. Sie können eine Methode für die Datennormalisierung angeben, die beim Kodieren numerischer Features verwendet werden soll, z. B.: `"norm": "normalization technique"`. Die folgenden Normalisierungstechniken werden unterstützt: + **"none"**   –   Normalisiert die numerischen Werte während der Kodierung nicht. + **"min-max"**   –   Normalisiert jeden Wert, indem der Mindestwert subtrahiert wird und der Wert dann durch die Differenz zwischen Maximalwert und Mindestwert dividiert wird. + **"standard"**   –   Normalisiert jeden Wert, indem er durch die Summe aller Werte dividiert wird. ## Bucket-numerische Features in Neptune ML Anstatt eine numerische Eigenschaft mit rohen Zahlen darzustellen, können Sie numerische Werte zu Kategorien kondensieren. Sie könnten beispielsweise das Alter von Personen in Kategorien wie Kinder (0–20), junge Erwachsene (20–40), Personen mittleren Alters (40–60) und ältere Menschen (ab 60) unterteilen. Mithilfe dieser numerischen Buckets würden Sie eine numerische Eigenschaft in eine Art kategorisches Feature transformieren. In Neptune ML können Sie die Kodierung einer numerischen Eigenschaft als Bucket-numerisches Feature veranlassen. Sie müssen zwei Dinge angeben: + Ein numerischer Bereich im Format ` "range": [a, b] `, wobei `a` und `b` Ganzzahlen sind. + Eine Bucket-Zahl im Format ` "bucket_cnt": c `, wobei `c` die Anzahl der Buckets ist, ebenfalls eine Ganzzahl. Neptune ML berechnet dann die Größe jedes Buckets als ` ( b - a ) / c ` und kodiert jeden numerischen Wert als Nummer des Buckets, zu dem er gehört. Jeder Wert kleiner als `a` wird als zum ersten Bucket gehörend betrachtet. Jeder Wert größer als `b` wird als zum letzten Bucket gehörend betrachtet. Sie können optional auch festlegen, dass numerische Werte zu mehr als einem Bucket gehören, indem Sie eine Größe für das Gleitfenster angeben, z. B.: ` "slide_window_size": s `. Dabei ist `s` eine Zahl. Neptune ML transformiert anschließend jeden numerischen Wert `v` der Eigenschaft in einen Bereich von ` v - s/2 ` bis ` v + s/2 ` und weist den Wert `v` jedem Bucket zu, den der Bereich abdeckt. Schließlich können Sie optional auch eine Möglichkeit zum Ausfüllen fehlender Werte für numerische Features und Bucket-numerische Features bereitstellen. Hierzu verwenden Sie ` "imputer": "imputation technique "`, wobei die Imputationstechnik entweder `"mean"`, `"median"` oder `"most-frequent"` ist. Wenn Sie keinen Imputer angeben, kann ein fehlender Wert dazu führen, dass die Verarbeitung angehalten wird. ## Text-Feature-Kodierung in Neptune ML Für Freiformtext kann Neptune ML mehrere verschiedene Modelle verwenden, um die Sequenz von Token in einer Eigenschaftswert-Zeichenfolge in einen Realwertvektor fester Größe zu konvertieren: + [`text_fasttext`](#machine-learning-fasttext-features)   –   Verwendet [fastText](https://fasttext.cc/)-Kodierung. Dies ist die empfohlene Kodierung für Features, die eine und nur eine der fünf Sprachen verwenden, die fastText unterstützt. + [`text_sbert`](#machine-learning-sbert-features)   –   Verwendet die Kodierungsmodelle [Sentence BERT](https://www.sbert.net/docs/pretrained_models.html#sentence-embedding-models) (SBERT). Dies ist die empfohlene Kodierung für Text, den `text_fasttext` nicht unterstützt. + [`text_word2vec`](#machine-learning-word2vec-features)   –   Verwendet die [Word2Vec](https://wikipedia.org/wiki/Word2vec)-Algorithmen (ursprünglich von [Google](https://code.google.com/archive/p/word2vec/) veröffentlicht), um Text zu kodieren. Word2Vec unterstützt nur Englisch. + [`text_tfidf`](#machine-learning-tfidf-features)   –   Verwendet den Vektorisierer [term frequency–inverse document frequency](https://wikipedia.org/wiki/Tf-idf) (TF-IDF) für die Textkodierung. Die TF-IDF-Kodierung unterstützt statistische Features, die von den anderen Kodierungen nicht unterstützt werden. ### *fastText*-Kodierung von Texteigenschaftswerten in Neptune ML Neptune ML kann die [fastText](https://fasttext.cc/)-Modelle verwenden, um Texteigenschaftswerte in Realwertvektoren fester Größe zu konvertieren. Dies ist die empfohlene Kodierungsmethode für Texteigenschaftswerte in einer der fünf Sprachen, die fastText unterstützt: + `en`   (Englisch) + `zh`   (Chinesisch) + `hi`   (Hindi) + `es`   (Spanisch) + `fr`   (Französisch) Beachten Sie, dass fastText keine Sätze verarbeiten kann, die Wörter in mehr als einer Sprache enthalten. Die Methode `text_fasttext` kann optional das Feld `max_length` verwenden, das die maximale Anzahl von Token in einem Texteigenschaftswert angibt, die kodiert werden sollen. Anschließend wird die Zeichenfolge abgeschnitten. Dies kann die Leistung verbessern, wenn Texteigenschaftswerte lange Zeichenfolgen enthalten, da fastText alle Token unabhängig von der Zeichenfolgenlänge kodiert, wenn `max_length` nicht angegeben ist. Dieses Beispiel gibt an, dass französische Filmtitel mit fastText kodiert werden: ``` { "file_name" : "nodes/movie.csv", "separator" : ",", "node" : ["~id", "movie"], "features" : [ { "feature": ["title", "title", "text_fasttext"], "language": "fr", "max_length": 1024 } ] } ``` ### Sentence BERT (SBERT)-Satzkodierung von Text-Features in Neptune ML Neptune ML kann die Sequenz von Token in einem Zeichenfolgen-Eigenschaftswert mithilfe von Sentence BERT (SBERT)-Modellen in einen Realwertvektor fester Größe konvertieren. Neptune unterstützt zwei SBERT-Methoden: `text_sbert128` (die Standardmethode, wenn Sie nur `text_sbert` angeben) und `text_sbert512`. Der Unterschied zwischen den beiden Methoden ist die maximale Länge einer kodierten Texteigenschaftswert-Zeichenfolge. Bei der `text_sbert128`-Kodierung werden Textzeichenfolgen nach der Kodierung von 128 Token abgeschnitten, während `text_sbert512` Textzeichenfolgen nach der Kodierung von 512 Token abschneidet. Daher erfordert `text_sbert512` mehr Verarbeitungszeit als `text_sbert128`. Beide Methoden sind langsamer als `text_fasttext`. Die SBERT-Kodierung ist mehrsprachig. Daher müssen Sie keine Sprache für den Eigenschaftswerttext angeben, den Sie kodieren. SBERT unterstützt zahlreiche Sprachen und kann einen Satz kodieren, der mehr als eine Sprache enthält. Wenn Sie Eigenschaftswerte kodieren, die Text in einer oder mehreren Sprachen enthalten, die fastText nicht unterstützt, ist SBERT die empfohlene Kodierungsmethode. Das folgende Beispiel gibt an, dass Filmtitel bis maximal 128 Token als SBERT kodiert werden: ``` { "file_name" : "nodes/movie.csv", "separator" : ",", "node" : ["~id", "movie"], "features" : [ { "feature": ["title", "title", "text_sbert128"] } ] } ``` ### Word2Vec-Kodierung von Text-Features in Neptune ML Neptune ML kann Zeichenfolgen-Eigenschaftswerte als Word2Vec-Feature kodieren. (Die [Word2Vec-Algorithmen](https://wikipedia.org/wiki/Word2vec) wurden ursprünglich von [Google](https://code.google.com/archive/p/word2vec/) veröffentlicht.) Die Methode `text_word2vec` kodiert die Token in einer Zeichenfolge als dichten Vektor unter Verwendung eines [von SpaCy trainierten Modells](https://spacy.io/models). Sie unterstützt nur die englische Sprache (unter Verwendung des Modells [en\$1core\$1web\$1lg](https://spacy.io/models/en#en_core_web_lg)). Das folgende Beispiel gibt an, dass Filmtitel mit Word2Vec kodiert werden: ``` { "file_name" : "nodes/movie.csv", "separator" : ",", "node" : ["~id", "movie"], "features" : [ { "feature": ["title", "title", "text_word2vec"], "language": "en_core_web_lg" } ] } ``` Beachten Sie, dass das Sprachfeld optional ist, da das englische `en_core_web_lg`-Modell das einzige Modell ist, das Neptune unterstützt. ### TF-IDF-Kodierung von Text-Features in Neptune ML Neptune ML kann Texteigenschaftswerte als `text_tfidf`-Features kodieren. Diese Kodierung konvertiert die Reihenfolge der Wörter im Text mittels des Vektorisierers [term frequency–inverse document frequency](https://wikipedia.org/wiki/Tf-idf) (TF-IDF) in einen numerischen Vektor, gefolgt von einer Operation zur Reduzierung der Dimensionalität. [TF-IDF](https://en.wikipedia.org/wiki/Tf%E2%80%93idf) (term frequency – inverse document frequency) ist ein numerischer Wert, der misst, wie wichtig ein Wort in einem Dokumentensatz ist. Er wird berechnet, indem die Häufigkeit, mit der ein Wort in einem bestimmten Eigenschaftswert vorkommt, durch die Gesamtzahl der Eigenschaftswerte dividiert wird, in denen es vorkommt. Wenn beispielsweise das Wort „Kiss“ zweimal in einem bestimmten Filmtitel vorkommt (z. B. „Kiss Kiss Bang Bang“) und „Kiss“ im Titel von insgesamt 4 Filmen vorkommt, dann wäre der TF-IDF-Wert für „Kiss“ im Titel „Kiss Kiss Bang Bang“ ` 2 / 4 `. Der Vektor, der ursprünglich erstellt wird, hat ***d*** Dimensionen, wobei ***d*** die Anzahl der eindeutigen Begriffe in allen Eigenschaftswerten dieses Typs ist. Die Operation zur Reduzierung der Dimensionalität verwendet eine randomisierte Projektion mit geringer Dichte, um diese Zahl auf maximal 100 zu reduzieren. Anschließend wird das Vokabular eines Diagramms generiert, indem alle enthaltenen `text_tfidf`-Features zusammengeführt werden. Sie können den TF-IDF-Vektorisierer auf verschiedene Arten steuern: + **`max_features`**   –   Mithilfe des Parameters `max_features` können Sie die Anzahl der Begriffe in `text_tfidf`-Features auf die häufigsten einschränken. Wenn Sie beispielsweise `max_features` auf 100 festlegen, sind nur die 100 am häufigsten verwendeten Begriffe enthalten. Wenn Sie `max_features` nicht explizit festlegen, ist der Standardwert 5 000. + **`min_df`**   –   Mithilfe des Parameters `min_df` können Sie die Anzahl der Begriffe in `text_tfidf`-Features auf Features einschränken, die mindestens mit einer angegebenen Häufigkeit im Dokumentsatz vorkommen. Wenn Sie beispielsweise `min_df` auf 5 festlegen, werden nur Begriffe verwendet, die in mindestens 5 verschiedenen Eigenschaftswerten vorkommen. Wenn Sie `min_df` nicht explizit festlegen, ist der Standardwert 2. + **`ngram_range`**   –   Der Parameter `ngram_range` bestimmt, welche Wortkombinationen als Begriffe behandelt werden. Wenn Sie beispielsweise `ngram_range` auf `[2, 4]` festlegen, würden die folgenden 6 Begriffe im Titel „Kiss Kiss Bang Bang“ vorkommen: + *Begriffe mit 2 Wörtern*:  „Kiss Kiss“, „Kiss Bang“ und „Bang Bang“. + *Begriffe mit 3 Wörtern*:  „Kiss Kiss Bang“ und „Kiss Bang Bang“. + *Begriffe mit 4 Wörtern*:  „Kiss Kiss Bang Bang“. Die Standardeinstellung für `ngram_range` ist `[1, 1]`. ## Datetime-Features in Neptune ML Neptune ML kann Teile von `datetime`-Eigenschaftswerten in kategorische Features konvertieren, indem sie als [One-Hot-Arrays](https://en.wikipedia.org/wiki/One-hot) kodiert werden. Verwenden Sie den Parameter `datetime_parts`, um einen oder mehrere der folgenden Teile für die Kodierung anzugeben: `["year", "month", "weekday", "hour"]`. Wenn Sie `datetime_parts` nicht festlegen, werden standardmäßig alle vier Teile kodiert. Wenn der Bereich der datetime-Werte beispielsweise die Jahre 2010 bis 2012 umfasst, sind die vier Teile des datetime-Eintrags `2011-04-22 01:16:34` wie folgt: + **year**   –   `[0, 1, 0]`. Da der Zeitraum nur 3 Jahre umfasst (2010, 2011 und 2012), hat das One-Hot-Array drei Einträge, einen für jedes Jahr. + **month**   –   `[0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0]`. Hier enthält das One-Hot-Array einen Eintrag für jeden Monat des Jahres. + **weekday**   –   `[0, 0, 0, 0, 1, 0, 0]`. Nach dem ISO-8601-Standard ist Montag der erste Tag der Woche. Da der 22. April 2011 ein Freitag war, ist das entsprechende One-Hot-Wochentag-Array an der fünften Position aktiviert. + **hour**   –   `[0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]`. Die Stunde 01:00 Uhr ist in einem One-Hot-Array mit 24 Elementen festgelegt. Tag des Monats, Minute und Sekunde sind nicht kategorisch kodiert. Wenn der betreffende `datetime`-Bereich nur Daten innerhalb eines einzigen Jahres umfasst, wird kein `year`-Array kodiert. Sie können eine Imputationsstrategie angeben, um fehlende `datetime`-Werte aufzufüllen, indem Sie den Parameter `imputer` und eine der für numerische Features verfügbaren Strategien verwenden. ## Auto-Feature-Kodierung in Neptune ML Anstatt die Feature-Kodierungsmethoden manuell anzugeben, die für die Eigenschaften im Diagramm verwendet werden sollen, können Sie `auto` als Feature-Kodierungsmethode festlegen. Neptune ML versucht dann, anhand des zugrunde liegenden Datentyps die beste Feature-Kodierung für jede Eigenschaft zu inferieren. Dies sind einige der Heuristiken, die Neptune ML bei der Auswahl der geeigneten Feature-Kodierungen verwendet: + Wenn die Eigenschaft nur numerische Werte besitzt und in numerische Datentypen konvertiert werden kann, kodiert Neptune ML sie im Allgemeinen als numerischen Wert. Wenn jedoch die Anzahl der eindeutigen Werte für die Eigenschaft weniger als 10 % der Gesamtzahl der Werte ist und die Kardinalität dieser eindeutigen Werte kleiner als 100 ist, verwendet Neptune ML eine kategorische Kodierung. + Wenn die Eigenschaftswerte in einen `datetime`-Typ konvertiert werden können, kodiert Neptune ML sie als `datetime`-Feature. + Wenn die Eigenschaftswerte in boolesche Werte (1/0 oder True/False) transformiert werden können, verwendet Neptune ML die Kategoriekodierung. + Wenn es sich bei der Eigenschaft um eine Zeichenfolge handelt, in der mehr als 10 % ihrer Werte eindeutig sind und die durchschnittliche Anzahl von Token pro Wert größer oder gleich 3 ist, inferiert Neptune ML den Eigenschaftstyp als Text und erkennt automatisch die verwendete Sprache. Wenn es sich bei der erkannten Sprache um eine der von [fastText](#machine-learning-fasttext-features) unterstützten Sprachen handelt (Englisch, Chinesisch, Hindi, Spanisch und Französisch), verwendet Neptune ML `text_fasttext` zur Kodierung des Texts. Andernfalls verwendet Neptune ML [`text_sbert`](#machine-learning-sbert-features). + Wenn die Eigenschaft eine nicht als Text-Feature klassifizierte Zeichenfolge ist, nimmt Neptune ML an, dass es sich um ein kategorisches Feature handelt, und verwendet die Kategoriekodierung. + Wenn jeder Knoten einen eigenen eindeutigen Wert für eine Eigenschaft hat, die als Kategorie-Feature inferiert wird, löscht Neptune ML die Eigenschaft aus dem Trainingsdiagramm, da es sich wahrscheinlich um eine ID handelt, die für das Lernen keine Informationen bereitstellt. + Wenn bekannt ist, dass die Eigenschaft gültige Neptune-Trennzeichen wie Semikolon („;“) enthält, kann Neptune ML die Eigenschaft nur als `MultiNumerical` oder `MultiCategorical` behandeln. + Neptune ML versucht zunächst, die Werte als numerische Features zu kodieren. Wenn dies erfolgreich ist, verwendet Neptune ML die numerische Kodierung, um numerische Vektor-Features zu erstellen. + Andernfalls kodiert Neptune ML die Werte als Werte mit mehreren Kategorien. + Wenn Neptune ML den Datentyp der Werte einer Eigenschaft nicht ableiten kann, Neptune MLdrops die Eigenschaft aus dem Trainingsdiagramm. # Bearbeiten einer Trainingsdaten-Konfigurationsdatei Der Neptune-Exportvorgang exportiert Neptune-ML-Daten aus einem Neptune-DB-Cluster in einen S3-Bucket. Er exportiert Knoten und Kanten getrennt in die Ordner `nodes/` und `edges/`. Er erstellt außerdem eine JSON-Konfigurationsdatei für Trainingsdaten, die standardmäßig den Namen `training-data-configuration.json` hat. Diese Datei enthält Informationen zum Schema des Diagramms, zu den Typen der Features, zu den Operationen für Feature-Transformation und -Normalisierung sowie zum Ziel-Feature für eine Klassifizierungs- oder Regressionsaufgabe. Es kann Fälle geben, in denen Sie Konfigurationsdatei direkt ändern möchten. Ein solcher Fall liegt vor, wenn Sie ändern möchten, wie Features verarbeitet werden oder wie das Diagramm konstruiert wird, ohne den Export jedes Mal erneut ausführen zu müssen, wenn Sie die Spezifikation für die Machine-Learning-Aufgabe ändern, die Sie lösen möchten. **Bearbeiten der Trainingsdaten-Konfigurationsdatei** 1. **Laden Sie die Datei zu Ihrem lokalen Computer herunter.** Wenn Sie nicht einen oder mehrere benannte Aufträge in dem an den Exportvorgang übergebenen Parameter `additionalParams/neptune_ml` angegeben haben, hat die Datei den Standardnamen, `training-data-configuration.json`. Sie können einen AWS CLI-Befehl wie diesen verwenden, um die Datei herunterzuladen: ``` aws s3 cp \ s3://(your Amazon S3 bucket)/(path to your export folder)/training-data-configuration.json \ ./ ``` 1. **Bearbeiten Sie die Datei mit einem Texteditor.** 1. **Laden Sie die geänderte Datei hoch.** Laden Sie die geänderte Datei mit einem AWS CLI-Befehl wie dem folgenden wieder an den gleichen Speicherort in Amazon S3 hoch, von dem Sie sie heruntergeladen haben: ``` aws s3 cp \ training-data-configuration.json \ s3://(your Amazon S3 bucket)/(path to your export folder)/training-data-configuration.json ``` # Beispiel für eine JSON-Konfigurationsdatei für Trainingsdaten Dies ist ein Beispiel für eine Trainingsdaten-Konfigurationsdatei, die ein Diagramm für eine Aufgabe zur Knotenklassifizierung beschreibt: ``` { "version" : "v2.0", "query_engine" : "gremlin", "graph" : [ { "edges" : [ { "file_name" : "edges/(movie)-included_in-(genre).csv", "separator" : ",", "source" : ["~from", "movie"], "relation" : ["", "included_in"], "dest" : [ "~to", "genre" ] }, { "file_name" : "edges/(user)-rated-(movie).csv", "separator" : ",", "source" : ["~from", "movie"], "relation" : ["rating", "prefixname"], # [prefixname#value] "dest" : ["~to", "genre"], "features" : [ { "feature" : ["rating", "rating", "numerical"], "norm" : "min-max" } ] } ], "nodes" : [ { "file_name" : "nodes/genre.csv", "separator" : ",", "node" : ["~id", "genre"], "features" : [ { "feature": ["name", "genre", "category"], "separator": ";" } ] }, { "file_name" : "nodes/movie.csv", "separator" : ",", "node" : ["~id", "movie"], "features" : [ { "feature": ["title", "title", "word2vec"], "language": ["en_core_web_lg"] } ] }, { "file_name" : "nodes/user.csv", "separator" : ",", "node" : ["~id", "user"], "features" : [ { "feature": ["age", "age", "numerical"], "norm" : "min-max", "imputation": "median", }, { "feature": ["occupation", "occupation", "category"], } ], "labels" : [ { "label": ["gender", "classification"], "split_rate" : [0.8, 0.2, 0.0] } ] } ] }, "warnings" : [ ] ] } ``` # Die Struktur der JSON-Konfigurationsdateien für Trainingsdaten Die Trainingskonfigurationsdatei verweist auf CSV-Dateien, die vom Exportvorgang in den Ordnern `nodes/` und `edges/` gespeichert wurden. In jeder Datei unter `nodes/` werden Informationen zu Knoten gespeichert, die dieselbe Eigenschaftsdiagramm-Knotenbezeichnung besitzen. Jede Spalte in einer Knotendatei speichert entweder die Knoten-ID oder die Knoteneigenschaft. Die erste Zeile der Datei enthält eine Kopfzeile mit der `~id` oder dem Eigenschaftsnamen für jede Spalte. In jeder Datei unter `edges/` werden Informationen zu Knoten gespeichert, die dieselbe Eigenschaftsdiagramm-Kantenbezeichnung besitzen. Jede Spalte in einer Knotendatei speichert entweder die Quellknoten-ID, die Zielknoten-ID oder die Kanteneigenschaft. Die erste Zeile der Datei enthält eine Kopfzeile mit `~from`, `~to` oder dem Eigenschaftsnamen für jede Spalte. Die Trainingsdaten-Konfigurationsdatei besitzt auf der obersten Ebene drei Elemente: ``` { "version" : "v2.0", "query_engine" : "gremlin", "graph" : [ ... ] } ``` + `version`   –   (Zeichenfolge) Die Version der verwendeten Konfigurationsdatei. + `query_engine`   –   (Zeichenfolge) Die Abfragesprache für den Export der Diagrammdaten. Zurzeit ist nur „Gremlin“ gültig. + `graph`   –   (JSON-Array) listet ein oder mehrere Konfigurationsobjekte auf, die Modellparameter für alle Knoten und Kanten enthalten, die verwendet werden sollen. Die Konfigurationsobjekte im Diagramm-Array haben die im nächsten Abschnitt beschriebene Struktur. ## Inhalt eines im `graph`-Array aufgelisteten Konfigurationsobjekts Ein Konfigurationsobjekt im `graph`-Array kann auf der obersten Ebene drei Knoten enthalten: ``` { "edges" : [ ... ], "nodes" : [ ... ], "warnings" : [ ... ], } ``` + `edges`   –   (Array von JSON-Objekten) Jedes JSON-Objekt gibt eine Reihe von Parametern an, um die Behandlung einer Kante im Diagramm während Modellverarbeitung und -training zu definieren. Dieser Knoten wird nur mit der Gremlin-Engine verwendet. + `nodes`   –   (Array von JSON-Objekten) Jedes JSON-Objekt gibt eine Reihe von Parametern an, um die Behandlung eines Knotens im Diagramm während Modellverarbeitung und -training zu definieren. Dieser Knoten wird nur mit der Gremlin-Engine verwendet. + `warnings`   –   (Array von JSON-Objekten) Jedes Objekt enthält eine Warnung, die während des Datenexportvorgangs generiert wird. ## Inhalt eines im `edges`-Array aufgelisteten Kantenkonfigurationsobjekts Ein in einem `edges`-Array aufgelistetes Kantenkonfigurationsobjekt kann auf der obersten Ebene die folgenden Felder enthalten: ``` { "file_name" : "(path to a CSV file)", "separator" : "(separator character)", "source" : ["(column label for starting node ID)", "(starting node type)"], "relation" : ["(column label for the relationship name)", "(the prefix name for the relationship name)"], "dest" : ["(column label for ending node ID)", "(ending node type)"], "features" : [(array of feature objects)], "labels" : [(array of label objects)] } ``` + **`file_name`**   –   Eine Zeichenfolge, die den Pfad zu einer CSV-Datei angibt, in der Informationen zu Kanten mit derselben Eigenschaftsdiagramm-Bezeichnung gespeichert werden. Die erste Zeile dieser Datei enthält eine Kopfzeile mit Spaltenbezeichnungen. Die ersten beiden Spaltenbezeichnungen sind `~from` und `~to`. In der ersten Spalte (die Spalte `~from`) wird die ID des Startknotens der Kante gespeichert. In der zweiten Spalte (die Spalte `~to`) wird die ID des Endknotens der Kante gespeichert. Die verbleibenden Spaltenbezeichnungen in der Kopfzeile geben für jede verbleibende Spalte den Namen der Kanteneigenschaft an, deren Werte in diese Spalte exportiert wurden. + **`separator`**   –   Eine Zeichenfolge mit dem Trennzeichen, das die Spalten in dieser CSV-Datei trennt. + **`source`**   –   Ein JSON-Array mit zwei Zeichenfolgen, die den Startknoten der Kante angeben. Die erste Zeichenfolge enthält den Kopfzeilennamen der Spalte, in der die Startknoten-ID gespeichert ist. Die zweite Zeichenfolge gibt den Knotentyp an. + **`relation`**   –   Ein JSON-Array mit zwei Zeichenfolgen, die den Beziehungstyp der Kante angeben. Die erste Zeichenfolge enthält den Kopfzeilennamen der Spalte, in der der Beziehungsname (`relname`) gespeichert ist. Die zweite Zeichenfolge enthält das Präfix für den Beziehungsnamen (`prefixname`). Der vollständige Beziehungstyp besteht aus den beiden Zeichenfolgen mit einem Bindestrich zwischen ihnen wie folgt: `prefixname-relname`. Wenn die erste Zeichenfolge leer ist, haben alle Kanten den gleichen Beziehungstyp, nämlich die `prefixname`-Zeichenfolge. + **`dest`**   –   Ein JSON-Array mit zwei Zeichenfolgen, die den Endknoten der Kante angeben. Die erste Zeichenfolge enthält den Kopfzeilennamen der Spalte, in der die Endknoten-ID gespeichert ist. Die zweite Zeichenfolge gibt den Knotentyp an. + **`features`**   –   Ein JSON-Array mit Eigenschaftswert-Feature-Objekten. Jedes Eigenschaftswert-Feature--Objekt enthält die folgenden Felder: + **feature**   –   Ein JSON-Array mit drei Zeichenfolgen. Die erste Zeichenfolge enthält den Kopfzeilennamen der Spalte, in der der Eigenschaftswert gespeichert ist. Die zweite Zeichenfolge enthält den Feature-Namen. Die dritte Zeichenfolge enthält den Feature-Typ. + **norm**   –   (*Optional*) Gibt die Normalisierungsmethode an, die auf die Eigenschaftswerte angewendet werden soll. + **`labels`**   –   Ein JSON-Array von Objekten. Jedes dieser Objekte definiert ein Ziel-Feature der Kanten und gibt die Proportionen der Kanten für die Trainings- und Validierungsphasen an. Jedes Objekt enthält die folgenden Felder: + **label**   –   Ein JSON-Array mit zwei Zeichenfolgen. Die erste Zeichenfolge enthält den Kopfzeilennamen der Spalte, in der der Ziel-Feature-Eigenschaftswert gespeichert ist. Die zweite Zeichenfolge gibt einen der folgenden Zielaufgabentypen an: + `"classification"`   –   Eine Aufgabe zur Kantenklassifizierung. Die Eigenschaftswerte in der Spalte, die durch die erste Zeichenfolge im `label`-Array identifiziert wird, werden als kategorische Werte behandelt. Bei einer Aufgabe zur Kantenklassifizierung darf die erste Zeichenfolge im `label`-Array nicht leer sein. + `"regression"`   –   Eine Kantenregressionsaufgabe. Die Eigenschaftswerte in der Spalte, die durch die erste Zeichenfolge im `label`-Array identifiziert wird, werden als numerische Werte behandelt. Für eine Aufgabe zur Kantenregression darf die erste Zeichenfolge im `label`-Array nicht leer sein. + `"link_prediction"`   –   Eine Aufgabe zur Linkvorhersage. Es sind keine Eigenschaftswerte erforderlich. Bei einer Aufgabe zur Linkvorhersage wird die erste Zeichenfolge im `label`-Array ignoriert. + **`split_rate`**   –   Ein JSON-Array mit drei Zahlen zwischen null und eins, die zusammen eins ergeben und eine Schätzung des Anteils der Knoten darstellen, die in der Trainings-, Validierungs- und Testphase jeweils verwendet werden. Sie können dieses Feld oder das Feld `custom_split_filenames` definieren, aber nicht beide. Siehe [split\$1rate](machine-learning-neptune_ml-targets.md#machine-learning-property-graph-neptune_ml-targets-split_rate). + **`custom_split_filenames`**   –   Ein JSON-Objekt, das die Dateinamen für die Dateien angibt, die die Trainings-, Validierungs- und Testpopulationen definieren. Sie können dieses Feld oder das Feld `split_rate` definieren, aber nicht beide. Weitere Informationen finden Sie unter [Benutzerdefinierte train-validation-test Proportionen](#machine-learning-custom-stages-splits). ## Inhalt eines im `nodes`-Array aufgelisteten Knotenkonfigurationsobjekts Ein in einem `nodes`-Array aufgelistetes Knotenkonfigurationsobjekt kann die folgenden Felder enthalten: ``` { "file_name" : "(path to a CSV file)", "separator" : "(separator character)", "node" : ["(column label for the node ID)", "(node type)"], "features" : [(feature array)], "labels" : [(label array)], } ``` + **`file_name`**   –   Eine Zeichenfolge, die den Pfad zu einer CSV-Datei angibt, in der Informationen zu Knoten mit derselben Eigenschaftsdiagramm-Bezeichnung gespeichert werden. Die erste Zeile dieser Datei enthält eine Kopfzeile mit Spaltenbezeichnungen. Die erste Spaltenbezeichnung ist `~id` und die erste Spalte (die Spalte `~id`) speichert die Knoten-ID. Die verbleibenden Spaltenbezeichnungen in der Kopfzeile geben für jede verbleibende Spalte den Namen der Knoteneigenschaft an, deren Werte in diese Spalte exportiert wurden. + **`separator`**   –   Eine Zeichenfolge mit dem Trennzeichen, das die Spalten in dieser CSV-Datei trennt. + **`node`**   –   Ein JSON-Array mit zwei Zeichenfolgen. Die erste Zeichenfolge enthält den Header-Namen der Spalte, in der der Knoten gespeichert ist IDs. Die zweite Zeichenfolge gibt den Knotentyp im Diagramm an, der einer Eigenschaftsdiagrammbezeichnung des Knotens entspricht. + **`features`**   –   Ein JSON-Array mit Knoten-Feature-Objekten. Siehe [Inhalt eines Feature-Objekts, das in einem `features`-Array für einen Knoten oder eine Kante aufgelistet ist](#machine-learning-graph-node-features-config). + **`labels`**   –   Ein JSON-Array mit Knotenbezeichnungsobjekten. Siehe [Inhalt eines im `labels`-Knoten-Array aufgelisteten Knotenbezeichnungsobjekts](#machine-learning-graph-node-labels-config). ## Inhalt eines Feature-Objekts, das in einem `features`-Array für einen Knoten oder eine Kante aufgelistet ist Ein in einem `features`-Array aufgelistetes Knoten-Feature-Objekt kann auf der obersten Ebene die folgenden Felder enthalten: + **`feature`**   –   Ein JSON-Array mit drei Zeichenfolgen. Die erste Zeichenfolge enthält den Kopfzeilennamen der Spalte, in der der Eigenschaftswert für das Feature gespeichert ist. Die zweite Zeichenfolge enthält den Feature-Namen. Die dritte Zeichenfolge enthält den Feature-Typ. Gültige Feature-Typen werden in [Mögliche Werte des Typfeldes für Features](machine-learning-neptune_ml-features.md#machine-learning-neptune_ml-feature-types) aufgelistet. + **`norm`**   –   Dies ist ein Pflichtfeld für numerische Features. Es gibt die Normalisierungsmethode an, die für numerische Werte verwendet werden soll: Gültige Werte sind `"none"`, `"min-max"` und „Standard“. Details dazu finden Sie unter [Das Normfeld](machine-learning-neptune_ml-features.md#machine-learning-neptune_ml-features-norm). + **`language`**   –   Das Feld für die Sprache gibt die Sprache an, die in Texteigenschaftswerten verwendet wird. Die Nutzung ist von der Textkodierungsmethode abhängig: + Dieses Feld ist für die [`text_fasttext`](machine-learning-feature-encoding.md#machine-learning-fasttext-features)-Kodierung erforderlich und es muss eine der folgenden Sprachen angegeben werden: + `en`   (Englisch) + `zh`   (Chinesisch) + `hi`   (Hindi) + `es`   (Spanisch) + `fr`   (Französisch) `text_fasttext` kann jedoch nicht mehr als eine Sprache gleichzeitig verarbeiten. + Dieses Feld wird für die [`text_sbert`](machine-learning-feature-encoding.md#machine-learning-fasttext-features)-Kodierung nicht verwendet, da die SBERT-Kodierung mehrsprachig ist. + Dieses Feld ist für die [`text_word2vec`](machine-learning-feature-encoding.md#machine-learning-word2vec-features)-Kodierung optional, da `text_word2vec` nur Englisch unterstützt. Wenn vorhanden, muss der Name des englischsprachigen Modells angegeben werden: ``` "language" : "en_core_web_lg" ``` + Dieses Feld wird für die [`tfidf`](machine-learning-feature-encoding.md#machine-learning-tfidf-features)-Kodierung nicht verwendet. + **`max_length`**   –   Dieses Feld ist optional für [`text_fasttext`](machine-learning-feature-encoding.md#machine-learning-fasttext-features)-Features. Es gibt die maximale Anzahl von Token in einem Eingabe-Text-Feature an, die kodiert werden. Text, der eingegeben wird, nachdem `max_length` erreicht wurde, wird ignoriert. Wenn Sie beispielsweise max\$1length auf 128 festlegen, werden alle Token in einer Textsequenz nach dem 128. Zeichen ignoriert. + **`separator`**  –   Dieses Feld wird optional mit den Features `category`, `numerical` und `auto` verwendet. Es gibt ein Zeichen an, das für die Aufteilung eines Eigenschaftswerts in mehrere kategorische oder numerische Werte verwendet werden kann: Siehe [Das Trennfeld](machine-learning-neptune_ml-features.md#machine-learning-neptune_ml-features-separator). + **`range`**  –   Dies ist ein Pflichtfeld für `bucket_numerical`-Features. Es gibt den Bereich der numerischen Werte an, die in Buckets aufgeteilt werden sollen. Siehe [Das Bereichsfeld](machine-learning-neptune_ml-features.md#machine-learning-neptune_ml-features-range). + **`bucket_cnt`**  –   Dies ist ein Pflichtfeld für `bucket_numerical`-Features. Es gibt die Anzahl der Buckets an, in die der numerische Bereich unterteilt werden soll, der durch den Parameter `range` definiert wird. Siehe [Bucket-numerische Features in Neptune ML](machine-learning-feature-encoding.md#machine-learning-bucket_numerical-features). + **`slide_window_size`**  –   Dieses Feld wird optional mit `bucket_numerical`-Features verwendet, um mehr als einem Bucket Werte zuzuweisen. Siehe [Das Feld slide\$1window\$1size](machine-learning-neptune_ml-features.md#machine-learning-neptune_ml-features-slide_window_size). + **`imputer`**  –   Dieses Feld wird optional mit `numerical`-, `bucket_numerical`- und `datetime`-Features verwendet, um eine Imputationstechnik zum Ausfüllen fehlender Werte bereitzustellen. Die unterstützten Imputationstechniken sind `"mean"`, `"median"` und `"most_frequent"`. Siehe [Das Imputer-Feld](machine-learning-neptune_ml-features.md#machine-learning-neptune_ml-features-imputer). + **`max_features`**  –   Dieses Feld wird optional von `text_tfidf`-Features verwendet, um die maximale Anzahl der Begriffe anzugeben, die kodiert werden sollen: Siehe [Das Feld max\$1features](machine-learning-neptune_ml-features.md#machine-learning-neptune_ml-features-max_features). + **`min_df`**  –   Dieses Feld wird optional von `text_tfidf`-Features verwendet, um die Mindesthäufigkeit von Begriffen anzugeben, die kodiert werden sollen: Siehe [Das Feld min\$1df](machine-learning-neptune_ml-features.md#machine-learning-neptune_ml-features-min_df). + **`ngram_range`**  –   Dieses Feld wird optional von `text_tfidf`-Features verwendet, um den Bereich von Wörtern oder Token anzugeben, die als potenzielle einzelne Begriffe zur Kodierung betrachtet werden sollen. Siehe [Das Feld ngram\$1range](machine-learning-neptune_ml-features.md#machine-learning-neptune_ml-features-ngram_range). + **`datetime_parts`**  –   Dieses Feld wird optional von `datetime`-Features verwendet, um anzugeben, welche Teile des datetime-Werts kategorisch kodiert werden sollen. Siehe [Das Feld datetime\$1parts](machine-learning-neptune_ml-features.md#machine-learning-neptune_ml-features-datetime_parts). ## Inhalt eines im `labels`-Knoten-Array aufgelisteten Knotenbezeichnungsobjekts Ein in einem `labels`-Knoten-Array aufgelistetes Bezeichnungsobjekt definiert ein Knotenziel-Feature und gibt die Proportionen der Knoten an, die in den Trainings-, Validierungs- und Testphasen verwendet werden. Jedes Objekt kann die folgenden Felder enthalten: ``` { "label" : ["(column label for the target feature property value)", "(task type)"], "split_rate" : [(training proportion), (validation proportion), (test proportion)], "custom_split_filenames" : {"train": "(training file name)", "valid": "(validation file name)", "test": "(test file name)"}, "separator" : "(separator character for node-classification category values)", } ``` + **`label`**   –   Ein JSON-Array mit zwei Zeichenfolgen. Die erste Zeichenfolge enthält den Kopfzeilennamen der Spalte, in der die Eigenschaftswerte für das Feature gespeichert sind. Die zweite Zeichenfolge gibt den Zielaufgabentyp an, der Folgendes sein kann: + `"classification"`   –   Eine Aufgabe zur Knotenklassifizierung. Die Eigenschaftswerte in der angegebenen Spalte werden verwendet, um ein kategorisches Feature zu erstellen. + `"regression"`   –   Eine Aufgabe zur Knotenregression. Die Eigenschaftswerte in der angegebenen Spalte werden verwendet, um ein numerisches Feature zu erstellen. + **`split_rate`**   –   Ein JSON-Array mit drei Zahlen zwischen null und eins, die zusammen eins ergeben und eine Schätzung des Anteils der Knoten darstellen, die in der Trainings-, Validierungs- und Testphase jeweils verwendet werden. Siehe [split\$1rate](machine-learning-neptune_ml-targets.md#machine-learning-property-graph-neptune_ml-targets-split_rate). + **`custom_split_filenames`**   –   Ein JSON-Objekt, das die Dateinamen für die Dateien angibt, die die Trainings-, Validierungs- und Testpopulationen definieren. Sie können dieses Feld oder das Feld `split_rate` definieren, aber nicht beide. Weitere Informationen finden Sie unter [Benutzerdefinierte train-validation-test Proportionen](#machine-learning-custom-stages-splits). + **`separator`**   –   Eine Zeichenfolge, die das Trennzeichen enthält, das kategorische Feature-Werte für eine Klassifizierungsaufgabe trennt. **Anmerkung** Wenn kein Bezeichnungsobjekt sowohl für Kanten als auch für Knoten angegeben wird, wird automatisch angenommen, dass es sich bei der Aufgabe um eine Linkvorhersage handelt. Die Kanten werden randomisiert in 90 % zum Training und 10 % zur Validierung aufgeteilt. ## Benutzerdefinierte train-validation-test Proportionen Standardmäßig wird der Parameter `split_rate` von Neptune ML verwendet, um das Diagramm anhand der im Parameter definierten Anteile randomisiert in Trainings-, Validierungs- und Testpopulationen aufzuteilen. Um eine genauere Kontrolle über die in diesen Populationen verwendeten Entitäten zu erhalten, können Dateien zu ihrer expliziten Definition erstellt werden. Anschließend [kann die Trainingsdaten-Konfigurationsdatei bearbeitet werden](machine-learning-processing-training-config-file.md), um diese indizierenden Dateien den Populationen zuzuordnen. Diese Zuordnung wird durch ein JSON-Objekt für den Schlüssel [`custom_split_filesnames`](#custom_split_filenames) in der Trainingskonfigurationsdatei spezifiziert. Wenn diese Option verwendet wird, müssen für die Schlüssel `train` und `validation` Dateinamen angegeben werden, optional auch für den Schlüssel `test`. Die Formatierung dieser Dateien sollte dem [Gremlin-Datenformat](bulk-load-tutorial-format-gremlin.md#bulk-load-tutorial-format-gremlin-systemheaders) entsprechen. Insbesondere bei Aufgaben auf Knotenebene sollte jede Datei eine Spalte mit der `~id` Überschrift enthalten, in der der Knoten aufgeführt ist IDs, und bei Aufgaben auf Kantenebene sollten die Dateien die Quell `~from` - `~to` bzw. Zielknoten der Kanten spezifizieren und angeben. Diese Dateien müssen am selben Amazon-S3-Speicherort platziert werden wie die exportierten Daten, die für die Datenverarbeitung verwendet werden (siehe [`outputS3Path`](export-parameters.md#export-parameters-outputS3Path)). Bei Aufgaben zur Klassifizierung oder Regression von Eigenschaften können diese Dateien optional die Bezeichnungen für die Machine-Learning-Aufgabe definieren. In diesem Fall müssen die Dateien eine Eigenschaftsspalte mit dem Kopfzeilennamen haben, der in der [Trainingsdaten-Konfigurationsdatei definiert](#machine-learning-graph-node-labels-config) ist. Wenn Eigenschaftsbezeichnungen sowohl in den exportierten Knoten- und Kantendateien als auch in den benutzerdefiniert aufgeteilten Dateien definiert sind, haben die benutzerdefiniert aufgeteilten Dateien Vorrang.