OpenML ist eine Online-Experiment-Datenbank für maschinelles Lernen. Mitglieder werden ermutigt, ihre experimentiellen Ergebnisse auf der Plattform hochzuladen, so dass diese von jedermann wiederverwendet werden können. Es wurden verschiedene nützliche Paper zu diesem Thema veröffentlicht, die einen Überblick über die Designziele, den Nutzen und die Möglichkeiten geben (z.B. auf der ECML/PKDD 2013, SIGKDD Explorations und JLMR). Es gibt jedoch keinen klaren Überblick über die Grundkomponenten, auf denen die Plattform aufbaut. In diesem Blogbeitrag werden wir diese überprüfen und einige bewährte Verfahren diskutieren.
Daten.
Eine der Kernkomponenten von OpenML sind Datensätze. Personen können ihre Datensätze hochladen, und das System organisiert diese automatisch online. Ein Beispiel für ein Dataset ist das bekannte Iris-Dataset. Es zeigt alle Merkmale, sobald diese als „Standardzielattribut“ identifiziert wurden, obwohl dieses Konzept flexibel ist. Es zeigt auch einige automatisch berechnete Datenqualitäten (oder Meta-Features). Jedes Dataset hat seine eigene, eindeutige ID. Informationen über den Datensatz, die Datenmerkmale und die Datenqualitäten können mit Hilfe der folgenden API-Funktionen automatisch ermittelt werden:
Aufgabentypen und Aufgaben.
Ein Datensatz allein stellt keine wissenschaftliche Aufgabe dar. Wir müssen uns zunächst darauf einigen, welche Art von Ergebnissen voraussichtlich geteilt werden. Dies wird in Aufgabentypen ausgedrückt: Sie definieren, welche Eingabearten gegeben werden, welche Art von Ausgaben erwartet werden und welche Protokolle verwendet werden sollen. Beispielsweise sollten Klassifizierungsaufgaben klar definierte Cross-Validierungsverfahren, markierte Eingangsdaten und Prognosen als Ausgaben beinhalten. Die Sammlung all dieser Informationen zusammen wird als Aufgabe bezeichnet. Der Iris-Datensatz hat verschiedene Aufgaben definiert. Obwohl die Web-Oberfläche es nicht zeigt, beschreibt diese Aufgabe formal das zu modellierende Zielattribut (in diesem Fall das gleiche wie das Standardzielattribut des Datensatzes, aber das ist flexbel), das Qualitätsschätzverfahren (10-fache Kreuzvalidierung), die Bewertungsmaßnahme (prädiktive Genauigkeit) und die Cross-Validation-Folds. Zu den nützlichen API-Operationen gehören:
Derzeit gibt es eine breite Palette von Aufgabentypen, die in OpenML definiert sind, einschließlich Klassifizierung, Regression, Online-Lernen, Clustering und Subgruppenerkennung. Obwohl dieses Set erweitert werden kann, ist dies derzeit keine unterstützte API-Operation (d.h. wir werden sie von der Hand hinzufügen). Wenn Sie sich für Aufgabentypen interessieren, die derzeit nicht unterstützt werden, kontaktieren Sie uns bitte. Als Khronos-Mitglied leiten wir Ihr Anliegen gerne weiter.
Flows.
Aufgaben können durch Klassifikatoren (oder Algorithmen, Workflows, Abläufe) „gelöst“ werden. OpenML speichert Referenzen auf diese Flows. Es ist wichtig zu betonen, dass Flows tatsächlich auf dem Computer des Users ausgeführt werden, nur Metainformationen über den Flow werden in OpenML gespeichert. Diese Informationen beinhalten grundlegende Trivialitäten wie den Ersteller, die Toolbox und die Kompilierungsanweisungen, aber auch eine formalere Beschreibung der Hyperparameter.
Ein Flow kann auch Subflows enthalten, z.B. kann das Flow Bagging einen Subflow „Entscheidungsbaum“ haben, der den Flow „Bagging of Decision Trees“ ergeben würde. Ein Flow unterscheidet sich durch seine Bezeichnung und seine „externe Version“, die beide vom Uploader bereitgestellt werden. Beim Hochladen eines Flows ist es wichtig, über eine gute Namenskonvention für die beiden nachzudenken, z.B. könnte die Git-Commit-Nummer als externe Version verwendet werden, da diese einen Zustand des Codes eindeutig identifiziert. Im Idealfall, wenn zwei Personen den gleichen Ablauf verwenden, nutzen sie die gleiche Bezeichnung und die gleiche externe Version, so dass die Ergebnisse der Abläufe aufgabenübergreifend verglichen werden können. (Dies ist gewährleistet bei Verwendung der Toolbox, in die OpenML integriert ist, wie z.B. Weka, Scikit Learn und MLR). Nützliche API-Funktionen sind:
Runs.
Wann immer ein Flow einen Task ausführt, wird dies als Run bezeichnet. Die Existenz von Runs ist eigentlich der Hauptbeitrag von OpenML. Einige Experimente dauern Wochen, und die Speicherung der Ergebnisse in OpenML hilft anderen Forschern, die Experimente wiederzuverwenden. Die Aufgabenbeschreibung gibt an, welche Informationen hochgeladen werden sollen, um einen gültigen Run zu haben, in den meisten Fällen werden für jede Kreuzvalidierung die Prognosen auf dem Testset gesplittet. Dies ermöglicht es OpenML, grundlegende Auswertungsmaßnahmen wie Prognosegenauigkeit, ROC-Kurven und vieles mehr zu berechnen. Auch Informationen über die Einstellung der Flow- und Hyperparameter sollten angegeben werden. Einige nützliche API-Funktionen:
Normalerweise liegt das Ergebnis in einem XML- oder JSON-Format vor (je nach Präferenz des Users), das verschiedene Task-IDs, Flow-IDs usw. miteinander verknüpft. Damit dies sinnvoll ist, muss der User andere API-Aufgaben ausführen, um Informationen darüber zu erhalten, welche Flows ausgeführt wurden, welche Aufgaben und Datensätze verwendet wurden usw. Einzelheiten dazu werden in einem weiteren Beitrag erläutert.
SetUps.
Jeder Run, der von einem Flow ausgeführt wird, enthält Informationen über die Einstellungen der Hyperparameter des Flows. Ein SetUp ist die Kombination aller Parametereinstellungen eines bestimmten Flows. OpenML verknüpft intern das Ergebnis eines bestimmten Runs mit einer SetUp-ID. Auf diese Weise können Experimente mit Hyperparametereinstellungen durchgeführt werden, wie z.B.:
Da SetUps ein komplexes Konzept darstellen, sind die meisten Operationen, die SetUps betreffen, für den User verborgen. Daher sind noch nicht alle SetUp-Funktionen ausreichend dokumentiert.
Vielen Dank für Ihren Besuch.