Evalml: Integre Woodwork DataTables en EvalML

Creado en 25 sept. 2020  ·  8Comentarios  ·  Fuente: alteryx/evalml

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:

  • Actualizar AutoML: 1 semana

    • Actualice AutoMLSearch para admitir WW DataTables. Mantener el soporte para la entrada de pandas.

    • AutoML seguirá pasando pandas DF a las canalizaciones/componentes

  • 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

    • Puede (y debe) hacerse en grupo
  • Actualice AutoML para pasar tablas de datos a cada canalización/componente en lugar de pandas DF. 1 día
  • Actualice los componentes desde la selección usando pandas dtypes hasta la selección usando tipos lógicos DataTable en su lugar. 3 días
  • Actualice la documentación para usar DataTables en todos los ejemplos. 2 días
  • Actualice todos los métodos gráficos, métodos útiles que aceptan datos, para admitir 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).

epic

Todos 8 comentarios

@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:

  1. Averigüe cuándo se agregará carpintería a conda (y/o ayude a acelerar eso). Mantenga las fusiones de carpintería hasta entonces. Porque necesitamos que se haga para liberar el código que depende de la carpintería.
  2. A corto plazo, haga que la carpintería sea una dependencia "opcional", lo que significa que si la importación falla, simplemente no admitiremos las tablas de carpintería como argumento para la búsqueda automática. A largo plazo, se siente torpe hacer esto para todos los métodos fit / predict de tubería/componente, especialmente si vamos a agregar carpintería a conda de todos modos, por lo que debemos evitar esto.
  3. Fusionar soporte de carpintería. Cualquier instalación conda de evalml tendrá errores de importación. Viva con esto hasta que la carpintería esté en conda.
  4. Fusionar soporte de carpintería. No suelte a conda hasta que la carpintería esté en conda.

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:

  • Actualizar las comprobaciones de datos (en curso)
  • Actualizar todos los componentes para usar tipos de carpintería donde corresponda (#1290)
  • Actualizar los métodos de comprensión del modelo
  • Devuelve carpintería en lugar de pandas desde la canalización/componente transform / predict , y en cualquier lugar devolvemos una copia o extensión de los datos ingresados ​​por el usuario.
  • Actualice nuestras listas de tipos de d anteriores y todos los usos para usar tipos de carpintería

@angela97lin ¿me perdí algo?

@dsherry ¡ Eso se ve bien!

  • Actualización de documentación para usar Woodwork (en proceso, #1466)
  • Actualizar las comprobaciones de datos (en curso, #1481)
  • Actualizar métodos de comprensión del modelo + gráficos no cubiertos en la documentación
  • Devuelva carpintería en lugar de pandas de tubería/componente transform / predict , y en cualquier lugar devolveremos una copia o extensión de los datos ingresados ​​por el usuario (#1406)
  • Actualice nuestras listas de tipos de d anteriores y todos los usos para usar tipos de carpintería #1290

@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? :)

¿Fue útil esta página
0 / 5 - 0 calificaciones