Dieses Epic verfolgt alle Probleme im Zusammenhang mit der Integration von Woodwork DataTables in EvalML.
Hinweise hier: https://alteryx.quip.com/XedaAs9HXc9f/EvalML-Woodwork-Table-Integration
Designdokument hier: https://alteryx.quip.com/Oa4aA6h0Rf2k/Woodwork-DataTable-Integration-Design-Document
Implementierungsplan:
Fügen Sie eine Dokumentation darüber hinzu, auf welche Typen wir erwarten, dass kategorische, numerische und Text festgelegt werden, damit automl Funktionen korrekt behandelt, und warnen Sie die Benutzer, was passieren kann, wenn Benutzer pandas DataFrames / numpy-Arrays übergeben. 2 Tage
Aktualisieren Sie Pipelines und alle Komponenten, um WW DataTables zu akzeptieren: 1 Woche
Insgesamt: 3 Wochen 3 Tage, dann 1 weitere Woche zum Erstellen von Grafiken/Utilitys.
Schlüsseldaten
Die Veröffentlichung im Oktober ist dienstags, der 27. Oktober.
Ziel
Vervollständigen Sie alle bis Freitag, den 6. November (4 Wochen). Auslieferung im Nov.-Release.
Stretch-Ziel
Alles außer graphing/utils bis zum Oktober-Release (27. Okt.).
@angela97lin : Ich denke, wir sollten neue Datentabellentypen löschen, die wir anfangs nicht unterstützen werden. Dann können wir diese von Fall zu Fall unterstützen. So:
dt = ... # woodwork datatable as input to automl search, for example
numeric_features = dt.select('numeric')
categorical_features = dt.select('categorical')
natural_language_features = dt.select('natural_language')
# then, in order to drop unsupported types, from here on out, don't use
# the other features which may still be held in the original datatable
Ein bemerkenswertes Beispiel: Der Betrugsdatensatz verwendet Lat/Long . Derzeit gibt es das als zwei unabhängige Floats weiter. Kurzfristig sollten wir einfach absteigen. Ich nehme an, wir könnten in zwei unabhängige Floats codieren, aber ich bezweifle, dass das gut funktioniert. Langfristig werden wir die Latlong-kompatiblen Primitive von featuretools verwenden wollen, um Features für diesen Typ zu erstellen.
Das macht Sinn?
@freddyaboulton hat heute einen guten Punkt angesprochen: Da wir evalml auf Conda versenden, müssen wir Holzarbeiten auf Conda haben, bevor wir erwarten können, dass Benutzer es installieren. Damit bleiben uns folgende Optionen für das weitere Vorgehen:
fit
/ predict
-Methoden von Pipelines/Komponenten zu tun, insbesondere wenn wir sowieso Holzarbeiten zu Conda hinzufügen, also sollten wir dies vermeiden.Ich bin ein Fan von Option 1, dh Holzarbeiten auf Conda zu bringen, weil ich glaube, dass wir das langfristig machen wollen.
Wie ich sehe, wurde bereits ein Problem für das Hinzufügen von Holzarbeiten zu Conda eingereicht. Ich werde dem nachgehen.
@dsherry Danke dafür! @gsheni hat hier erwähnt, dass sie wahrscheinlich gegen Ende der Woche ein Update haben werden. Sollten wir dann mit der Zusammenführung für die Oktober-Veröffentlichung warten?
@angela97lin ja, angesichts der Tatsache, dass die Veröffentlichung in ein paar Tagen ist und du auch eine Weile unterwegs sein wirst, sollte es nicht zu viel Mühe bereiten, mit der Zusammenführung bis danach zu warten.
Habe gerade mit @angela97lin und @freddyaboulton über das Holzarbeiten-Upgrade geplaudert. Hier ist, was wir als derzeit ausstehend / im Flug aufgeführt haben:
transform
/ predict
zurück, und überall geben wir eine Kopie oder Erweiterung der vom Benutzer eingegebenen Daten zurück.@angela97lin habe ich etwas verpasst?
@dsherry Das sieht ungefähr richtig aus!
transform
/ predict
zurück, und überall geben wir eine Kopie oder Erweiterung der vom Benutzer eingegebenen Daten zurück (#1406)@angela97lin super , danke!
@chukarsten @dsherry Alle Probleme im Zusammenhang mit diesem Epic wurden geschlossen! Ist es sicher, dieses Epos zu schließen und nur Probleme zu verfolgen und zu verfolgen, die isoliert auftreten? :)