Datei: /// C: / Users / /AppData/Roaming/SAS/JMP/Addins/com.jmp.xgboost/XGBoost%20Add-In.pdf
Seite 5:
XGBoost> XGBoost
Der Menüeintragsname der zweiten Ebene ist redundant und verwirrend.
Ich würde etwas vorschlagen, das klar auf die zu ergreifenden Maßnahmen hinweist, wie z. B. "Fit-Modell".
Seite 6:
"Wenn Sie eine einzelne Holdout-Analyse anstelle von k-fach durchführen möchten, ändern Sie den Typ der Validierungsvariablen in" Kontinuierlich "und stellen Sie sicher, dass die Werte 0 für das Training und 1 für die Validierung vorliegen."
Es ist schön, dass es einen Weg gibt, diese Arbeit zu machen, aber sie ist so wie sie ist nicht zu entdecken. Dies sollte in der Benutzeroberfläche explizit angegeben werden. Ein Kontrollkästchen zum Beispiel.
Add-In-Benutzeroberfläche
Ich denke, es wäre viel besser für den Benutzer, wenn das Add-In neue Menüeinträge unter dem Menü "Analysieren" zusammen mit den derzeit vorhandenen Algorithmen hinzufügen würde. Ich meine, XGBoost sollte unter sein Analysieren> Predictive Modeling , nach dem Boosted Tree . Ich verstehe, dass dies eher eine Einschränkung des JMP-Menüanpassungssystems ist, das Add-In-Autoren ausgesetzt ist.
XGBoost UI Model UI
Das LRT verfügt über die Option "Python-Code generieren ...", die vom veröffentlichten Modell im Formel-Depot verwendet wird.
Der generierte Code unterscheidet sich jedoch deutlich, und es gibt keinen eindeutigen Hinweis darauf, warum ein Benutzer einen über den anderen verwenden sollte. Ich schlage vor, verschiedene Namen und eine Erklärung im Tooltip-Text zu verwenden, wie sie sich unterscheiden.
Verschiedene Namen erleichtern es auch, sie im Skriptindex zu finden, wo zusätzliche Informationen zu ihren Unterschieden bereitgestellt werden können.
Add-In Python Generierter Code:
xgboost_jmp.py
"# Bitte senden Sie Kommentare, Vorschläge, Korrekturen an russ.wolfinger@jmp.com"
Es ist besser, ein Unternehmenskonto wie tech.support@jmp.com zu verwenden, als ein Einzelkonto.
Pandas als pd importieren
Obwohl Pandas eine gute Wahl für eine generische tabellarische Datenmanipulationsbibliothek für Python ist, schließt dies die Verwendung neuer Bibliotheken aus, die eine höhere Leistung und Skalierbarkeit bieten, wie z cuDF und Dask . Durch das Codieren gegen eine Adapterschnittstelle und das Bereitstellen einer Standardimplementierung für Pandas können Benutzer von einer Standardimplementierung profitieren, während andere Bereitstellungsoptionen weiterhin offen bleiben. Es sollte nicht schwierig sein, da diese neuen Bibliotheken versuchen, der Pandas-API so weit wie möglich zu folgen und manchmal sogar Drop-In-Ersetzungen bereitzustellen. Insbesondere ein POC, der unseren generierten Code zeigt, der ein Dask-Dataset bewertet, das größer als der Arbeitsspeicher ist, mehrere Threads verwendet oder möglicherweise sogar über einen Cluster verteilt ist, wäre ein gutes Verkaufsargument dafür, wie JMP es Benutzern ermöglicht, das Python-Ökosystem mit minimalem Aufwand zu nutzen.
Import Seaborn
importiere matplotlib.pyplot als plt
Das Hinzufügen von Code zur Visualisierung der Ergebnisse ist nett, aber für ein Bereitstellungsszenario ein totes Gewicht. Ich würde diese Funktionalität in einem separaten Modul bereitstellen und den Bereitstellungscode so leicht wie möglich halten, was die Abhängigkeit betrifft.
Ich meine, Datenvisualisierung ist gut für eine Demo, aber in der Produktion ist sie einfach nicht nützlich. Der generierte Code sollte für Produktionsszenarien IMO optimiert werden.
def feature_name_replace (f)
Diese Methode kann zwei unterschiedliche Feature-Namen demselben Namen zuordnen, wodurch Namenskonflikte mit möglicherweise schwerwiegenden Folgen entstehen. Beispiel: feature_name_replace ("A (1)") == feature_name_replace ("A.1_") == "A_1_".
Der aufrufende Code prüft nicht auf einen solchen Konflikt.
Es mag unwahrscheinlich sein, aber da wir nicht kontrollieren, wie der Benutzer seine Variablen benennt, sollten wir danach suchen.
def main (mname, Pfad, df, yvar, xvar, wvar, vvar, cvar, parms, iter, action = 'fit',
verbose_eval = 100, verbose = True, plot = True):
# parms: xgboost-Parameter, nur diejenigen, die sich von den Standardeinstellungen unterscheiden, werden benötigt
Es gibt keine Dokumentation für den gültigen oder erwarteten Inhalt des Wörterbuchs 'parms'.
Vielleicht ein Hinweis darauf, wo sie zu finden sind?
# action = 'fit': Passen Sie xgboost-Modelle mit wiederholter k-facher Kreuzvalidierung an
# action = 'vorhersagen': Neue Daten vorhersagen, binäre Modellobjekte müssen bereits im Unterverzeichnis mod gespeichert sein
Es gibt keine Überprüfung auf Aktion = 'Vorhersagen'. Es scheint, dass die Hauptfunktion immer versucht, das Modell zu bewerten. Ist das notwendig, wenn der Benutzer nur das Modell anpassen möchte?
Außerdem wird der Code auskommentiert, der das Modell auf der Festplatte speichern würde, wenn action = 'fit'. Daher gibt es derzeit keine Möglichkeit, das angepasste Modell später wiederzuverwenden, wenn Sie die Aktion == 'Vorhersagen' angeben.
# Modell Binärobjekt speichern
# xg.save_model (fname)
# print (fname)
# versbose_eval: Wie oft xgboost-Iterationen gedruckt werden sollen
Tippfehler.
# plot: Plot tatsächlich gegen vorhergesagt, wenn action == 'fit'
Siehe die obigen Kommentare zur Nützlichkeit der Plotfunktionen.
Formula Depot Generierter Code:
Ich habe die LRT-Option zum Veröffentlichen auf dem FD verwendet und dann die FD-Option zum Generieren von Python-Code verwendet (siehe Kommentar oben zur Wiederverwendung des Menüaktionsnamens).
Die generierte Scoring-Code-Datei scheint korrekt zu sein und enthält keine Platzhalter. Theoretisch wäre es bereit, eingesetzt zu werden. Das Problem ist, dass ähnliche Modelle von unseren Kunden vor Ort erstellt werden ( Verknüpfung ) Das Modell ist zu groß und stürzt den Python-Interpreter ab. Die Zeilenanzahl für ein Modell, das für PowderMetarllugy unter Verwendung der in der Hilfe vorgeschlagenen Standardwerte generiert wurde, liegt nahe bei 82 KB Codezeilen.
Es gibt viele Möglichkeiten, dieses Problem zu beheben, von der Reduzierung der Anzahl temporärer Variablen bis zur Aufteilung des generierten Codes in mehrere kleinere Dateien (oder zumindest Funktionen). Es gibt schon eine Defekt dafür geöffnet, aber es ist keine Priorität.
Neben den oben beschriebenen generischen Optimierungen für große Modelle könnten die Besonderheiten des XGBoost-Modells wie die Vermeidung fehlender Werte und die Verwendung der One-Hot-Codierung sehr wahrscheinlich genutzt werden, um eine schlankere Darstellung zu erzielen, indem einige der darin enthaltenen Überprüfungen und Transformationen vermieden werden die generische Codegenerierungs-Engine.
Scoring Code Validation
Angenommen, wir können Modelle erhalten, die klein genug sind, um ausgeführt zu werden, ohne den Python-Interpreter zum Absturz zu bringen. Haben wir die Bewertungsergebnisse des von Formula Depot generierten Bewertungscodes mit den Bewertungsergebnissen des vom Python-Wrapper generierten Binärmodells verglichen? Ich denke, es wäre wichtig zu wissen, dass die generierten Zahlen tatsächlich gleich sind. Es gibt ein Testtool für diese Art der Validierung, das in Perforce unter gespeichert ist
// depot / main / test / Scoring / Python /.
Ich glaube, es könnte mit sehr wenigen Änderungen verwendet werden, wenn überhaupt.
xgb_jmp_m1.py
Dies scheint die POC-Datei zu sein, die zeigt, wie die Bibliothek verwendet wird.
Ein Jupyter-Notizbuch wäre die bessere Wahl, da es heutzutage das häufigste Fahrzeug für diese Art von Szenario ist: "Hier erfahren Sie, wie Sie meine Bibliothek verwenden".
Es wäre auch ein besserer Ort für den Plotcode, der derzeit Teil von xgboost_jmp.py ist
