file: /// C: / Users / /AppData/Roaming/SAS/JMP/Addins/com.jmp.xgboost/XGBoost%20Add-In.pdf
Page 5:
XGBoost> XGBoost
Le nom de l'entrée de menu de deuxième niveau est redondant et déroutant.
Je suggérerais quelque chose qui indique clairement l'action sur le point d'être prise, comme "fit model".
Page 6:
"Si vous souhaitez effectuer une analyse d'exclusion unique au lieu d'un facteur k, modifiez le type de la variable de validation en continu et assurez-vous qu'elle a les valeurs 0 pour la formation et 1 pour la validation."
C'est bien qu'il y ait un moyen de faire ce travail, mais c'est impossible à découvrir tel quel. Cela devrait être rendu explicite dans l'interface utilisateur. Un contrôle de case à cocher par exemple.
Interface utilisateur du complément
Je pense que ce serait beaucoup mieux pour l'utilisateur si le complément ajoutait de nouvelles entrées de menu sous le menu Analyser, ainsi que les algorithmes actuellement existants. Je veux dire, XGBoost devrait être sous Analyser> Modélisation prédictive , après Arbre boosté . Je comprends qu'il s'agit plus probablement d'une limitation du système de personnalisation de menu JMP exposé aux auteurs de compléments.
Interface utilisateur du modèle d'interface utilisateur XGBoost
Le LRT a une option "Générer du code Python ...", qui est le même nom utilisé par le modèle publié dans le dépôt de formules.
Cependant, le code généré est nettement différent et il n'y a aucune indication claire de la raison pour laquelle un utilisateur devrait utiliser l'un par rapport à l'autre. Je suggère d'utiliser des noms différents et une explication dans le texte de l'info-bulle sur leur différence.
Des noms différents faciliteront également leur recherche dans l'index de script, où des informations supplémentaires sur leurs différences peuvent être fournies.
Add-in Python Generated code:
xgboost_jmp.py
"# Veuillez envoyer vos commentaires, suggestions, corrections à russ.wolfinger@jmp.com"
Il serait préférable d'utiliser un compte d'entreprise, tel que tech.support@jmp.com, plutôt qu'un compte individuel.
importer des pandas en tant que pd
Bien que Pandas soit un bon choix en tant que bibliothèque générique de manipulation de données tabulaires pour Python, en supposant que cela exclut l'utilisation de nouvelles bibliothèques offrant des performances et une évolutivité supérieures, telles que cuDF et Dask . Le codage par rapport à une interface d'adaptateur et la fourniture d'une implémentation par défaut pour Pandas permettraient aux utilisateurs de bénéficier d'une implémentation par défaut tout en gardant la porte ouverte sur d'autres options de déploiement. Cela ne devrait pas être difficile car ces nouvelles bibliothèques essaient de suivre le plus possible l'API Pandas, offrant parfois même des remplacements instantanés. En particulier, un POC montrant notre code généré évaluant un ensemble de données Dask plus grand que la mémoire ne peut contenir, en utilisant plusieurs threads ou peut-être même un calcul distribué sur un cluster serait un excellent argument de vente pour la façon dont JMP permet aux utilisateurs de tirer parti de l'écosystème Python avec un minimum d'effort.
importer seaborn
importer matplotlib.pyplot comme plt
Ajouter du code pour visualiser les résultats est bien, mais c'est un poids mort pour un scénario de déploiement. Je fournirais cette fonctionnalité dans un module séparé et garderais le code de déploiement aussi léger que possible en ce qui concerne la dépendance.
Je veux dire, la visualisation des données est bien pour une démo mais en production, ce n'est tout simplement pas utile. Le code généré doit être optimisé pour les scénarios de production, IMO.
def feature_name_replace (f)
Cette méthode peut mapper deux noms d'entités distinctes sur le même nom, générant des conflits de dénomination avec des conséquences potentiellement néfastes. Par exemple, feature_name_replace ("A (1)") == feature_name_replace ("A.1_") == "A_1_".
Le code appelant ne vérifie pas un tel conflit.
Cela peut être peu probable, mais comme nous ne contrôlons pas la façon dont l'utilisateur nommera ses variables, nous devrions le vérifier.
def main (mname, path, df, yvar, xvar, wvar, vvar, cvar, parms, iter, action = 'fit',
verbose_eval = 100, verbose = True, plot = True):
# parms: paramètres xgboost, seuls ceux qui diffèrent des valeurs par défaut sont nécessaires
Il n'y a pas de documentation sur le contenu valide ou attendu du dictionnaire 'parms'.
Peut-être un pointeur vers où ils peuvent être trouvés?
# action = 'fit': ajustement des modèles xgboost avec validation croisée répétée de K-fold
# action = 'prédire': prédire de nouvelles données, les objets du modèle binaire doivent déjà être enregistrés dans le sous-répertoire mod
Il n'y a pas de contrôle pour action = 'prédire', il semble que la fonction principale tentera toujours d'évaluer le modèle. Est-ce nécessaire au cas où l'utilisateur souhaite uniquement adapter le modèle?
En outre, le code qui enregistrerait le modèle sur le disque lorsque action = 'fit' est commenté. Il n'y a donc actuellement aucun moyen de réutiliser le modèle ajusté ultérieurement lors de la spécification de l'action == 'prédire'
# enregistrer l'objet binaire du modèle
# xg.save_model (fname)
# print (fname)
# versbose_eval: à quelle fréquence imprimer les itérations xgboost
Faute de frappe.
# plot: tracer le réel par rapport au prédit lorsque l'action == 'fit'
Voir les commentaires ci-dessus sur l'utilité des capacités de traçage.
Code généré par Formula Depot:
J'ai utilisé l'option LRT pour publier sur le FD, puis j'ai utilisé l'option FD pour générer du code Python (voir le commentaire ci-dessus sur la réutilisation du nom de l'action de menu).
Le fichier de code de scoring généré semble être correct et ne comporte aucun espace réservé. En théorie, il serait prêt à être déployé. Le problème est qu'à l'instar des modèles similaires générés sur le terrain par nos clients ( lien ) le modèle est trop volumineux et plante l'interpréteur Python. Le nombre de lignes pour un modèle généré pour PowderMetarllugy en utilisant les valeurs par défaut comme suggéré dans l'aide est proche de 82K lignes de code.
Il existe de nombreuses façons de résoudre ce problème, de la réduction du nombre de variables temporaires à la division du code généré en plusieurs fichiers plus petits (ou au moins des fonctions). Il y a déjà un défaut ouvert pour cela mais ce n'est pas une priorité.
Outre les optimisations génériques pour les grands modèles décrites ci-dessus, les particularités du modèle XGBoost telles que l'évitement des valeurs manquantes et l'utilisation de l'encodage one-hot pourraient très probablement être exploitées pour générer une représentation allégée, en évitant certaines des vérifications et transformations présentes dans le moteur de génération de code générique.
Validation du code de notation
En supposant que nous puissions obtenir des modèles suffisamment petits pour fonctionner sans planter l'interpréteur Python, avons-nous comparé les résultats de notation du code de notation généré par Formula Depot avec les résultats de notation du modèle binaire généré par le wrapper Python? Je pense qu'il serait important de savoir que les chiffres générés sont effectivement les mêmes. Il existe un outil de test conçu pour ce type de validation stocké dans Perforce à
// dépôt / main / test / Scoring / Python /.
Je pense qu'il pourrait être utilisé avec très peu de changements, voire aucun.
xgb_jmp_m1.py
Cela semble être le fichier POC montrant comment utiliser la bibliothèque.
Un notebook Jupyter serait un meilleur choix, car c'est le véhicule le plus courant pour ce genre de scénario «voici comment utiliser ma bibliothèque» de nos jours.
Ce serait également un meilleur endroit pour le code de traçage qui fait actuellement partie de xgboost_jmp.py
