archivo: /// C: / Users / /AppData/Roaming/SAS/JMP/Addins/com.jmp.xgboost/XGBoost%20Add-In.pdf
Página 5:
XGBoost> XGBoost
El nombre de la entrada del menú del segundo nivel es redundante y confuso.
Sugeriría algo que indique claramente la acción que se va a tomar, como "ajustar el modelo".
Página 6:
"Si desea realizar un único análisis de exclusión en lugar de k-fold, cambie el tipo de la variable Validación a Continua y asegúrese de que tenga valores 0 para entrenamiento y 1 para validación".
Es bueno que haya una manera de hacer que esto funcione, pero no se puede descubrir tal como está. Esto debe hacerse explícito en la interfaz de usuario. Un control de casilla de verificación, por ejemplo.
IU de complemento
Creo que sería mucho mejor para el usuario si el complemento agregara nuevas entradas de menú en el menú Analizar, junto con los algoritmos existentes actualmente. Quiero decir, XGBoost debería estar debajo Analizar> Modelado predictivo , después Árbol potenciado . Entiendo que esto es más probable que sea una limitación del sistema de personalización de menús de JMP expuesto a los autores de complementos.
Interfaz de usuario del modelo de interfaz de usuario de XGBoost
El LRT tiene una opción "Generar código Python ...", que es el mismo nombre que usa el modelo publicado en Formula Depot.
Sin embargo, el código generado es marcadamente diferente y no hay una indicación clara de por qué un usuario debería usar uno sobre el otro. Sugiero usar nombres diferentes y una explicación en el texto de información sobre herramientas de cómo se diferencian.
Los diferentes nombres también facilitarán su búsqueda en el Índice de secuencias de comandos, donde se puede proporcionar información adicional sobre sus diferencias.
Complemento de código generado por Python:
xgboost_jmp.py
"# Envíe sus comentarios, sugerencias y correcciones a russ.wolfinger@jmp.com"
Sería mejor utilizar una cuenta corporativa, como tech.support@jmp.com, en lugar de una cuenta individual.
importar pandas como pd
Aunque Pandas es una buena opción en lo que respecta a una biblioteca genérica de manipulación de datos tabulares para Python, asumiendo que excluye el uso de nuevas bibliotecas que brindan mayor rendimiento y escalabilidad, como cuDF y Dask . Codificar contra una interfaz de adaptador y proporcionar una implementación predeterminada para Pandas permitiría a los usuarios beneficiarse de una implementación predeterminada mientras se mantiene la puerta abierta a otras opciones de implementación. No debería ser difícil ya que estas nuevas bibliotecas intentan seguir la API de Pandas tanto como sea posible, a veces incluso proporcionando reemplazos directos. En particular, un POC que muestre nuestro código generado con un puntaje de un conjunto de datos Dask más grande de lo que la memoria puede contener, usando múltiples subprocesos o quizás incluso computación distribuida en un clúster sería un gran punto de venta de cómo JMP permite a los usuarios aprovechar el ecosistema Python con el mínimo esfuerzo.
importar seaborn
importar matplotlib.pyplot como plt
Agregar código para visualizar los resultados es bueno, pero es un peso muerto para un escenario de implementación. Proporcionaría esa funcionalidad en un módulo separado y mantendría el código de implementación lo más ligero posible en lo que respecta a la dependencia.
Quiero decir, la visualización de datos es buena para una demostración, pero en producción, simplemente no es útil. El código generado debe optimizarse para escenarios de producción, en mi opinión.
def feature_name_replace (f)
Este método puede asignar dos nombres de características distintos al mismo nombre, generando conflictos de nombres con consecuencias potencialmente negativas. Por ejemplo, feature_name_replace ("A (1)") == feature_name_replace ("A.1_") == "A_1_".
El código de llamada no comprueba este tipo de conflicto.
Puede que sea poco probable, pero como no controlamos cómo el usuario nombrará sus variables, deberíamos comprobarlo.
def main (mname, path, df, yvar, xvar, wvar, vvar, cvar, parms, iter, action = 'fit',
verbose_eval = 100, verbose = True, plot = True):
# parms: xgboost parámetros, solo se necesitan aquellos diferentes de los predeterminados
No hay documentación para el contenido válido o esperado del diccionario 'parms'.
¿Quizás un indicador de dónde se pueden encontrar?
# action = 'fit': ajuste modelos xgboost con validación cruzada repetida de k-fold
# action = 'predecir': predice nuevos datos, los objetos del modelo binario ya deben estar guardados en el subdirectorio mod
No hay verificación de acción = 'predecir', parece que la función principal siempre intentará evaluar el modelo. ¿Es eso necesario en caso de que el usuario solo quiera ajustar el modelo?
Además, se comenta el código que guardaría el modelo en el disco cuando action = 'fit'. Por lo tanto, actualmente no hay forma de reutilizar el modelo ajustado más adelante al especificar action == 'predecir'
# guardar modelo de objeto binario
# xg.save_model (fname)
# print (fname)
# versbose_eval: con qué frecuencia imprimir iteraciones xgboost
Error de tipografía.
# trama: traza lo real frente a lo previsto cuando la acción == 'encaja'
Consulte los comentarios anteriores sobre la utilidad de las capacidades de trazado.
Código generado de Formula Depot:
Usé la opción LRT para publicar en el FD y luego usé la opción FD para generar código Python (ver el comentario anterior sobre la reutilización del nombre de la acción del menú).
El archivo de código de puntuación generado parece ser correcto y no tiene marcadores de posición. En teoría, estaría listo para ser desplegado. El problema es que, al igual que los modelos similares generados en campo por nuestros clientes ( enlace ) el modelo es demasiado grande y bloquea el intérprete de Python. El recuento de líneas para un modelo generado para PowderMetarllugy usando los valores predeterminados como se sugiere en la ayuda es cercano a 82K líneas de código.
Hay muchas formas posibles de abordar este problema, desde reducir el número de variables temporales hasta dividir el código generado en varios archivos más pequeños (o al menos funciones). Ya hay un defecto abierto para eso pero no es una prioridad.
Además de las optimizaciones genéricas para modelos grandes como se describió anteriormente, las particularidades del modelo XGBoost, como evitar valores perdidos y el uso de codificación one-hot, muy probablemente podrían aprovecharse para generar una representación más ágil, evitando algunas de las verificaciones y transformaciones presentes en el motor de generación de código genérico.
Validación del código de puntuación
Suponiendo que podemos obtener modelos lo suficientemente pequeños para ejecutar sin fallar el intérprete de Python, ¿hemos comparado los resultados de puntuación del código de puntuación generado por Formula Depot con los resultados de puntuación del modelo binario generado por el contenedor de Python? Creo que sería importante saber que los números generados son los mismos. Hay una herramienta de prueba construida para este tipo de validación almacenada en Perforce en
// depot / main / test / Scoring / Python /.
Creo que podría usarse con muy pocos cambios, si es que hay alguno.
xgb_jmp_m1.py
Este parece ser el archivo POC que muestra cómo usar la biblioteca.
Una computadora portátil Jupyter sería una mejor opción, ya que es el vehículo más común para este tipo de escenario de "aquí es cómo usar mi biblioteca" en la actualidad.
También sería un mejor lugar para el código de trazado que actualmente forma parte de xgboost_jmp.py
