file: /// C: / Users / /AppData/Roaming/SAS/JMP/Addins/com.jmp.xgboost/XGBoost%20Add-In.pdf
Pagina 5:
XGBoost> XGBoost
Il nome della voce di menu di secondo livello è ridondante e confuso.
Suggerirei qualcosa che indichi chiaramente l'azione che sta per essere intrapresa, come "modello adatto".
Pagina 6:
"Se desideri eseguire una singola analisi di controllo invece di k-fold, modifica il tipo della variabile di convalida in Continuo e assicurati che abbia valori 0 per l'addestramento e 1 per la convalida."
È bello che ci sia un modo per far funzionare questo, ma è introvabile così com'è. Questo dovrebbe essere reso esplicito nell'interfaccia utente. Un controllo della casella di controllo per esempio.
Interfaccia utente del componente aggiuntivo
Penso che sarebbe molto meglio per l'utente se il componente aggiuntivo aggiungesse nuove voci di menu nel menu Analizza, insieme agli algoritmi attualmente esistenti. Voglio dire, XGBoost dovrebbe essere sotto Analizza> Modellazione predittiva , dopo Albero potenziato . Capisco che questa sia più probabilmente una limitazione del sistema di personalizzazione dei menu JMP esposto agli autori di componenti aggiuntivi.
XGBoost UI Model UI
L'LRT ha un'opzione "Genera codice Python ...", che è lo stesso nome utilizzato dal modello pubblicato in Formula Depot.
Tuttavia, il codice generato è notevolmente diverso e non vi è alcuna chiara indicazione del motivo per cui un utente dovrebbe usarne uno sull'altro. Suggerisco di utilizzare nomi diversi e una spiegazione nel testo del suggerimento di come differiscono.
Nomi diversi renderanno anche più facile trovarli nell'indice di scripting, dove possono essere fornite informazioni aggiuntive sulle loro differenze.
Codice aggiuntivo generato da Python:
xgboost_jmp.py
"# Si prega di inviare commenti, suggerimenti, correzioni a russ.wolfinger@jmp.com"
Sarebbe meglio utilizzare un account aziendale, come tech.support@jmp.com, invece di un account individuale.
importa i panda come pd
Sebbene Pandas sia una buona scelta per quanto riguarda una libreria generica di manipolazione dei dati tabulari per Python, supponendo che precluda l'uso di nuove librerie che forniscono prestazioni e scalabilità più elevate, come cuDF e Dask . La codifica su un'interfaccia adattatore e la fornitura di un'implementazione predefinita per Pandas consentirebbe agli utenti di beneficiare di un'implementazione predefinita mantenendo comunque la porta aperta su altre opzioni di distribuzione. Non dovrebbe essere difficile dato che queste nuove librerie cercano di seguire l'API di Pandas il più possibile, a volte anche fornendo sostituzioni immediate. In particolare, un POC che mostra il nostro codice generato assegnando un punteggio a un set di dati Dask più grande della memoria può contenere, utilizzando più thread o forse anche l'elaborazione distribuita su un cluster sarebbe un ottimo punto di forza per il modo in cui JMP consente agli utenti di sfruttare l'ecosistema Python con il minimo sforzo.
importare seaborn
importa matplotlib.pyplot come plt
L'aggiunta di codice per visualizzare i risultati è utile, ma è un peso morto per uno scenario di distribuzione. Fornirei quella funzionalità in un modulo separato e manterrei il codice di distribuzione il più leggero possibile per quanto riguarda la dipendenza.
Voglio dire, la visualizzazione dei dati è utile per una demo ma in produzione non è utile. Il codice generato dovrebbe essere ottimizzato per gli scenari di produzione, IMO.
def feature_name_replace (f)
Questo metodo può mappare due nomi di funzionalità distinti allo stesso nome, generando conflitti di denominazione con conseguenze potenzialmente negative. Ad esempio, feature_name_replace ("A (1)") == feature_name_replace ("A.1_") == "A_1_".
Il codice chiamante non controlla tale conflitto.
Potrebbe essere improbabile ma poiché non controlliamo come l'utente chiamerà le sue variabili, dovremmo controllarlo.
def main (mname, path, df, yvar, xvar, wvar, vvar, cvar, parms, iter, action = 'fit',
verbose_eval = 100, verbose = True, plot = True):
# parms: parametri xgboost, sono necessari solo quelli diversi dai valori predefiniti
Non esiste documentazione per i contenuti validi o previsti del dizionario "parms".
Forse un puntatore a dove possono essere trovati?
# action = 'fit': adatta i modelli xgboost con ripetuta convalida incrociata k-fold
# action = 'forecast': prevede nuovi dati, gli oggetti del modello binario devono già essere salvati nella sottodirectory mod
Non c'è controllo per azione = 'previsione', sembra che la funzione principale tenterà sempre di valutare il modello. È necessario nel caso in cui l'utente desideri solo adattare il modello?
Inoltre, il codice che salverebbe il modello su disco quando action = 'fit' è commentato. Quindi al momento non c'è modo di riutilizzare il modello adattato in seguito quando si specifica l'azione == 'predire'
# salva l'oggetto binario del modello
# xg.save_model (fname)
# print (fname)
# versbose_eval: quanto spesso stampare le iterazioni xgboost
Errore di battitura.
# plot: trama reale rispetto a quella prevista quando l'azione == 'adatta'
Vedere i commenti sopra sull'utilità delle funzionalità di plottaggio.
Codice generato da Formula Depot:
Ho usato l'opzione LRT per pubblicare su FD e poi ho usato l'opzione FD per generare codice Python (vedi commento sopra sul riutilizzo del nome dell'azione di menu).
Il file di codice di punteggio generato sembra essere corretto e non ha segnaposto. In teoria, sarebbe pronto per essere schierato. Il problema è che come modelli simili generati sul campo dai nostri clienti ( collegamento ) il modello è troppo grande e blocca l'interprete Python. Il conteggio delle righe per un modello generato per PowderMetarllugy utilizzando i valori predefiniti suggeriti nella guida è vicino a 82.000 righe di codice.
Esistono molti modi possibili per risolvere questo problema, dalla riduzione del numero di variabili temporanee alla suddivisione del codice generato in più file più piccoli (o almeno funzioni). Esiste già un file difetto aperto per quello ma non è una priorità.
Oltre alle ottimizzazioni generiche per i modelli di grandi dimensioni come descritto sopra, le particolarità del modello XGBoost come evitare i valori mancanti e l'uso della codifica one-hot potrebbero molto probabilmente essere sfruttate per generare una rappresentazione più snella, evitando alcuni dei controlli e delle trasformazioni presenti in il motore di generazione del codice generico.
Convalida del codice di punteggio
Supponendo di poter ottenere modelli abbastanza piccoli da essere eseguiti senza bloccare l'interprete Python, abbiamo confrontato i risultati del punteggio del codice di punteggio generato da Formula Depot con i risultati del punteggio del modello binario generato dal wrapper Python? Penso che sarebbe importante sapere che i numeri generati sono effettivamente gli stessi. Esiste uno strumento di test creato per questo tipo di convalida archiviato in Perforce all'indirizzo
// depot / main / test / Scoring / Python /.
Credo che potrebbe essere utilizzato con pochissime modifiche, se del caso.
xgb_jmp_m1.py
Questo sembra essere il file POC che mostra come utilizzare la libreria.
Un notebook Jupyter sarebbe una scelta migliore, poiché è il veicolo più comune per questo tipo di scenario "ecco come usare la mia libreria" al giorno d'oggi.
Sarebbe anche un posto migliore per il codice di stampa che attualmente fa parte di xgboost_jmp.py
