Roadmap#

Zweck dieses Dokuments#

Dieses Dokument listet allgemeine Richtungen auf, die Kernbeitragende in der Entwicklung von scikit-learn sehen möchten. Die Tatsache, dass ein Punkt hier aufgeführt ist, ist keineswegs eine Garantie, dass er umgesetzt wird, da die Ressourcen begrenzt sind. Vielmehr ist es ein Hinweis darauf, dass Hilfe zu diesem Thema willkommen ist.

Zweckbestimmung: Scikit-learn im Jahr 2018#

Elf Jahre nach der Gründung von Scikit-learn hat sich in der Welt des maschinellen Lernens viel verändert. Wichtige Änderungen sind:

  • Rechenwerkzeuge: Die Nutzung von GPUs, verteilte Programmierframeworks wie Scala/Spark usw.

  • Hochrangige Python-Bibliotheken für Experimente, Verarbeitung und Datenmanagement: Jupyter Notebook, Cython, Pandas, Dask, Numba…

  • Veränderungen im Fokus der Forschung zum maschinellen Lernen: Anwendungen der künstlichen Intelligenz (bei denen die Eingabestruktur entscheidend ist) mit Deep Learning, Representation Learning, Reinforcement Learning, Domain Transfer usw.

Eine subtilere Veränderung im letzten Jahrzehnt ist, dass aufgrund sich ändernder Interessen im ML Doktoranden im Bereich maschinelles Lernen eher zu PyTorch, Dask usw. beitragen als zu Scikit-learn, sodass unser Beitragspool sich stark von dem vor einem Jahrzehnt unterscheidet.

Scikit-learn bleibt in der Praxis sehr beliebt für das Ausprobieren kanonischer Techniken des maschinellen Lernens, insbesondere für Anwendungen in den experimentellen Wissenschaften und in der Datenwissenschaft. Vieles von dem, was wir anbieten, ist nun sehr ausgereift. Aber die Pflege kann kostspielig sein, und wir können daher keine beliebigen neuen Implementierungen aufnehmen. Dennoch ist Scikit-learn auch entscheidend für die Definition eines API-Frameworks zur Entwicklung von interoperablen Komponenten für maschinelles Lernen außerhalb der Kernbibliothek.

Daher sind unsere Hauptziele in dieser Ära::

  • die kontinuierliche Pflege einer qualitativ hochwertigen, gut dokumentierten Sammlung von kanonischen Werkzeugen für die Datenverarbeitung und das maschinelle Lernen innerhalb des aktuellen Umfangs (d.h. rechteckige Daten, die weitgehend invariant gegenüber Spalten- und Zeilenreihenfolge sind; Vorhersage von Zielvariablen mit einfacher Struktur)

  • die Verbesserung der Benutzerfreundlichkeit bei der Entwicklung und Veröffentlichung externer Komponenten

  • die Verbesserung der Interoperabilität mit modernen Werkzeugen der Datenwissenschaft (z.B. Pandas, Dask) und Infrastrukturen (z.B. verteilte Verarbeitung)

Viele der feingranulareren Ziele finden Sie unter dem Tag API im Issue Tracker.

Architektonische / allgemeine Ziele#

Die Liste ist nicht als Prioritätenliste nummeriert, sondern um das Verweisen auf bestimmte Punkte zu erleichtern. Bitte fügen Sie neue Einträge nur am Ende hinzu. Beachten Sie, dass durchgestrichene Einträge bereits erledigt sind und wir versuchen, das Dokument bei der Arbeit an diesen Problemen aktuell zu halten.

  1. Verbesserte Handhabung von Pandas DataFrames

    • aktuelle Handhabung dokumentieren

  2. Verbesserte Handhabung von kategorischen Merkmalen

    • Baumbasierte Modelle sollten sowohl kontinuierliche als auch kategorische Merkmale verarbeiten können #29437.

    • Handhabung von Mischungen aus kategorischen und kontinuierlichen Variablen

  3. Verbesserte Handhabung fehlender Daten

    • Sicherstellen, dass Meta-Schätzer nachsichtig gegenüber fehlenden Daten sind, indem ein gemeinsamer Test implementiert wird.

    • Ein Amputations-Stichprobengenerator, um Teile eines Datensatzes fehlen zu lassen #6284

  4. Didaktischere Dokumentation

    • Es wurden immer mehr Optionen zu scikit-learn hinzugefügt. Infolgedessen ist die Dokumentation überladen, was es für Anfänger schwierig macht, den Überblick zu behalten. Es könnte etwas Arbeit geleistet werden, um die Informationen zu priorisieren.

  5. Weitergabe von Informationen, die nicht (X, y) sind: Merkmals-Eigenschaften

    • Die Handhabung pro Merkmal (z.B. "Ist dies ein nominaler / ordinaler / englischer Text?") sollte idealerweise auch nicht an Konstruktoren von Schätzern übergeben werden müssen, sondern als Metadaten neben X verfügbar sein. #8480

  6. Weitergabe von Informationen, die nicht (X, y) sind: Zielinformationen

    • Wir haben Probleme, den vollständigen Klassensatz an alle Komponenten zu übermitteln, wenn die Daten aufgeteilt/gesampelt werden. #6231 #8100

    • Wir haben keine Möglichkeit, eine Mischung aus kategorischen und kontinuierlichen Zielvariablen zu handhaben.

  7. Externe Benutzer können leichter mit Scikit-learn kompatible Komponenten schreiben

    • Selbstständigeres Betreiben von scikit-learn-contrib oder einer ähnlichen Ressource

  8. Unterstützung für Resampling und Stichprobenreduktion

    • Zulassen von Subsampling von Mehrheitsklassen (in einer Pipeline?) #3855

  9. Bessere Schnittstellen für die interaktive Entwicklung

    • Verbesserung der HTML-Visualisierungen von Schätzern über estimator_html_repr.

    • Mehr Plot-Tools, nicht nur als Beispiele.

  10. Verbesserte Werkzeuge für Modell-Diagnostik und grundlegende Inferenz

    • Arbeit an einer einheitlichen Schnittstelle für "Feature-Wichtigkeit"

    • bessere Wege zur Handhabung von Validierungsdatensätzen beim Anpassen (fitting)

  11. Bessere Werkzeuge zur Auswahl von Hyperparametern bei transduktiven Schätzern

    • Grid-Suche und Kreuzvalidierung sind für die meisten Clustering-Aufgaben nicht anwendbar. Stabilitätsbasierte Auswahl ist relevanter.

  12. Bessere Unterstützung für manuelles und automatisches Pipeline-Building

    • Einfachere Konstruktion komplexer Pipelines und gültiger Suchräume #7608 #5082 #8243

    • Bereitstellung von Suchbereichen für gängige Schätzer??

    • vgl. searchgrid

  13. Verbesserte Nachverfolgung des Anpassens (fitting)

    • Verbose ist nicht sehr benutzerfreundlich und sollte eine Standard-Logging-Bibliothek verwenden #6929, #78

    • Callbacks oder ein ähnliches System würden Logging und Early Stopping erleichtern

  14. Verteilte Parallelität

    • Akzeptieren von Daten, die __array_function__ entsprechen

  15. Ein Weg nach vorn für mehr Out-of-Core-Verarbeitung

    • Dask ermöglicht einfache Out-of-Core-Berechnungen. Während das Dask-Modell wahrscheinlich nicht auf alle Algorithmen des maschinellen Lernens übertragbar ist, ist ein Großteil des maschinellen Lernens auf kleineren Daten als ETL, daher können wir uns vielleicht an sehr große Skalen anpassen und nur einen Bruchteil der Muster unterstützen.

  16. Abwärtskompatible De-/Serialisierung einiger Schätzer

    • Derzeit bricht die Serialisierung (mit pickle) über Versionen hinweg. Obwohl wir möglicherweise andere Einschränkungen von pickle bezüglich Sicherheit usw. nicht umgehen können, wäre es großartig, eine versionsübergreifende Sicherheit ab Version 1.0 anzubieten. Hinweis: Gael und Olivier denken, dass dies eine hohe Wartelast verursachen kann und wir die Kompromisse verwalten sollten. Eine mögliche Alternative wird im folgenden Punkt vorgestellt.

  17. Dokumentation und Werkzeuge für das Lebenszyklusmanagement von Modellen

    • Gute Praktiken für Modell-Deployments und Lebenszyklus dokumentieren: Vor dem Deployment eines Modells: Snapshot der Code-Versionen (numpy, scipy, scikit-learn, benutzerdefiniertes Code-Repo), des Trainingsskripts und eines Alias, wie historische Trainingsdaten abgerufen werden können + Snapshot einer Kopie eines kleinen Validierungsdatensatzes + Snapshot der Vorhersagen (Vorhersagewahrscheinlichkeiten für Klassifikatoren) auf diesem Validierungsdatensatz.

    • Dokumentation und Werkzeuge, um das Upgrade von scikit-learn-Versionen einfach zu verwalten

      • Versuchen, das alte pickle zu laden. Wenn es funktioniert, verwenden Sie den Snapshot der Validierungsdatensatz-Vorhersagen, um festzustellen, dass das serialisierte Modell immer noch dasselbe Verhalten zeigt;

      • Wenn joblib.load / pickle.load nicht funktioniert, verwenden Sie das versionierte Kontroll-Trainingsskript + den historischen Trainingsdatensatz, um das Modell neu zu trainieren, und verwenden Sie den Snapshot der Validierungsdatensatz-Vorhersagen, um zu überprüfen, ob die frühere Vorhersageleistung wiederhergestellt werden kann: Wenn dies nicht der Fall ist, gibt es wahrscheinlich einen Fehler in scikit-learn, der gemeldet werden muss.

  18. Alles in scikit-learn sollte wahrscheinlich unserem API-Vertrag entsprechen. Wir treffen noch Entscheidungen zu einigen dieser damit verbundenen Themen.

    • Pipeline <pipeline.Pipeline> und FeatureUnion ändern ihre Eingabeparameter beim Anpassen (fit). Die Behebung dieses Problems erfordert, dass wir die Anwendungsfälle gut verstehen, um sicherzustellen, dass die gesamte aktuelle Funktionalität erhalten bleibt. #8157 #7382

  19. (Optional) Verbesserung der Suite für gemeinsame Tests von scikit-learn, um sicherzustellen, dass (zumindest für häufig verwendete) Modelle stabile Vorhersagen über Versionen hinweg haben (zu diskutieren);

    • Erweiterung der Dokumentation, um die Bereitstellung von Modellen in Python-freien Umgebungen zu erwähnen, z.B. ONNX. und Verwendung der oben genannten Best Practices, um die Vorhersagekonsistenz zwischen scikit-learn und ONNX-Vorhersagefunktionen auf dem Validierungsdatensatz zu bewerten.

    • Dokumentieren Sie gute Praktiken zur Erkennung von zeitlichen Verteilungsdrifts für bereitgestellte Modelle und gute Praktiken für das Neutrainieren mit neuen Daten, ohne katastrophale Leistungseinbußen zu verursachen.