Este Epic rastrea todos los problemas relacionados con la integración de Woodwork DataTables en EvalML.
Notas aquí: https://alteryx.quip.com/XedaAs9HXc9f/EvalML-Woodwork-Table-Integration
Documento de diseño aquí: https://alteryx.quip.com/Oa4aA6h0Rf2k/Woodwork-DataTable-Integration-Design-Document
Plan de IMPLEMENTACION:
Agregue documentación sobre los tipos que esperamos que se establezcan categóricos, numéricos y de texto para que automl trate las funciones correctamente, y advierta a los usuarios lo que puede suceder si los usuarios pasan pandas DataFrames / numpy arrays. 2 días
Actualice las canalizaciones y todos los componentes para aceptar WW DataTables: 1 semana
Total: 3 semanas 3 días, luego 1 semana más para hacer gráficos/utilidades.
Fechas clave
El lanzamiento de octubre es el martes 27 de octubre.
Meta
Complete todo antes del viernes 6 de noviembre (4 semanas). Envío en lanzamiento de noviembre.
Amplíe su meta
Todo excepto gráficos/utilidades hecho por el lanzamiento de octubre (27 de octubre).
@angela97lin : Creo que deberíamos eliminar nuevos tipos de tablas de datos que inicialmente no admitiremos. Luego podemos agregar soporte para aquellos en una base de caso por caso. Entonces:
dt = ... # woodwork datatable as input to automl search, for example
numeric_features = dt.select('numeric')
categorical_features = dt.select('categorical')
natural_language_features = dt.select('natural_language')
# then, in order to drop unsupported types, from here on out, don't use
# the other features which may still be held in the original datatable
Un ejemplo notable: el conjunto de datos de fraude usa lat/long . Actualmente, pasa eso como dos flotadores independientes. A corto plazo, deberíamos caer. Supongo que podríamos codificar en dos flotantes independientes, pero dudo que funcione bien. A largo plazo, querremos usar las primitivas compatibles con latlong de featuretools para crear funciones para ese tipo.
¿Eso tiene sentido?
@freddyaboulton mencionó un buen punto hoy: debido a que enviamos evalml en conda, necesitamos que la carpintería esté en conda antes de que podamos esperar que los usuarios la tengan instalada. Eso nos deja con las siguientes opciones sobre cómo proceder:
fit
/ predict
de tubería/componente, especialmente si vamos a agregar carpintería a conda de todos modos, por lo que debemos evitar esto.Soy partidario de la opción 1, es decir, poner madera en conda, porque creo que eso es lo que querremos hacer a largo plazo.
Veo que ya hay un problema presentado para agregar carpintería a conda. Seguiré
@dsherry ¡ Gracias por esto! @gsheni mencionó aquí que probablemente tendrán una actualización cerca del final de la semana. Entonces, ¿deberíamos esperar a fusionarnos para el lanzamiento de octubre?
@angela97lin sí, dado que el lanzamiento es en unos días, y que también estarás fuera por un tiempo, no debería ser demasiado problema esperar para fusionarse hasta después.
Estaba charlando con @angela97lin y @freddyaboulton sobre la actualización de la carpintería. Esto es lo que enumeramos como actualmente pendiente / en vuelo:
transform
/ predict
, y en cualquier lugar devolvemos una copia o extensión de los datos ingresados por el usuario.@angela97lin ¿me perdí algo?
@dsherry ¡ Eso se ve bien!
transform
/ predict
, y en cualquier lugar devolveremos una copia o extensión de los datos ingresados por el usuario (#1406)@angela97lin impresionante, gracias!
@chukarsten @dsherry ¡Se han cerrado todos los problemas asociados con esta epopeya! ¿Es seguro cerrar este Epic y solo rastrear y WW los problemas que surgen de forma aislada? :)