Evalml: Admite la parametrización de las comprobaciones de datos; hacer que InvalidTargetDataCheck valide el objetivo usando problem_type

Creado en 15 jul. 2020  ·  6Comentarios  ·  Fuente: alteryx/evalml

Corrige #970.

Según la discusión con @freddyaboulton en el n.° 929, sería bueno si pudiéramos pasar información adicional a DataChecks. Esto requeriría actualizar la API de DataCheck y considerar cómo interactúa con AutoML, ya que no instanciamos una instancia de DataChecks y solo pasamos una clase de DataChecks como parámetro a search() .

enhancement

Comentario más útil

Sabes qué, @angela97lin @freddyaboulton usemos este problema para rastrear a) la actualización de automl y la API de verificación de datos para admitir la parametrización yb) la actualización InvalidTargetDataCheck para validar el objetivo y generar errores inteligentes, para todo el objetivo tipos que admitimos.

Lo menciono porque acabo de presentar un error n. ° 970 y, al mirar más de cerca, el problema se solucionaría con lo anterior. Entonces esto cerrará #970.

Todos 6 comentarios

@ angela97lin , ¿podría describir el caso de uso para esto?

@dsherry ¡Claro! En el n.° 929, @freddyaboulton y yo discutíamos que sería bueno si el InvalidTargetDataCheck pudiera ser aún más útil si estuviera al tanto del tipo de problema que está manejando. Por ejemplo, si sabíamos que nuestro problema era de clasificación binaria pero la entrada a la verificación de datos tenía más de dos clases, podríamos generar una advertencia/error. Por lo tanto, sería bueno poder pasar parámetros de alguna manera o simplemente más información a la verificación de datos. Desafortunadamente, esto no funciona bien con nuestro diseño actual, donde pasamos clases y no instancias.

Alternativamente, podríamos crear clases de verificación de datos para cada tipo de problema, como BinaryClassificationInvalidTargetDataCheck, pero esto también podría ser bastante difícil al determinar qué debe incluir DefaultDataChecks (¿o también debería dividirse en DefaultBinaryClassificationDataChecks?)

Acabo de hablar con @angela97lin @freddyaboulton

Nos gusta la idea de reflejar el patrón que usamos para component_graph en las canalizaciones:

  • La lista de comprobaciones de datos se puede especificar inicialmente para la búsqueda automática como una lista de subclases DataCheck (o lo mismo pero dentro DataChecks ), no instancias
  • Una vez que la búsqueda automática quiere ejecutar las comprobaciones de datos, puede crear una instancia de la clase DataChecks
  • En ese momento, le pasaríamos un data_check_parameters , similar a nuestra canalización parameters , que contiene una configuración opcional para una o más comprobaciones de datos.
  • Si los usuarios quieren usar DataChecks directamente, pueden seguir un patrón similar
  • data_check_parameters debería estar predeterminado en None para que las personas no necesiten crear eso si no es necesario. Pero si falta un argumento requerido en una verificación de datos (como problem_type para algunos), eso debería generar un error de inicialización

Aquí hay un boceto de cómo podría verse esto en la búsqueda automática:

# today this helper standardizes the input to a list of `DataCheck` instances, and wraps that in a `DataChecks` instance
# after this work, this would standardize the input to a `DataChecks` class.
# if `data_checks` was already a `DataChecks` class, do nothing. else if `data_checks` is a list of `DataCheck` classes, define a `AutoMLDataChecks` class to wrap and return that
data_checks_class = self._validate_data_checks(data_checks)
# next we create the `DataChecks` instance by passing in data checks parameters
data_check_parameters = {'Target Datatype Data Check': {'problem_type': self.problem_type}}
data_checks = data_checks_class(data_check_parameters)
data_check_results = data_checks.validate(X, y)

El uso directo sería similar.

Próximos pasos

  • @angela97lin @freddyaboulton otros revisan el boceto anterior y lo revisan con cordura
  • @angela97lin presentará un problema para rastrear la adición de una verificación de datos TargetDatatype (nombre por determinar), según nuestra discusión en #960. Esa verificación de datos requeriría que se pasara un parámetro problem_type
  • ¡Quienquiera que tome este número también debe tomar ese TargetDatatype al mismo tiempo y construir esto! 🛠️ 😁

@dsherry ¡Me parece bien el plan! Lo único que agregaría es que prefiero aumentar el InvalidTargetDataCheck ya existente en lugar de crear una nueva verificación de datos, pero cualquier enfoque me funcionaría. Quienquiera que tome esto, asegúrese de verificar que el objetivo solo tenga dos valores únicos cuando el problem_type es binario. Esto fue mencionado en la revisión de #929.

if problem_type == "binary" and len(set(y)) != 2:
    # Warn that we do not have two unique values in y

Sabes qué, @angela97lin @freddyaboulton usemos este problema para rastrear a) la actualización de automl y la API de verificación de datos para admitir la parametrización yb) la actualización InvalidTargetDataCheck para validar el objetivo y generar errores inteligentes, para todo el objetivo tipos que admitimos.

Lo menciono porque acabo de presentar un error n. ° 970 y, al mirar más de cerca, el problema se solucionaría con lo anterior. Entonces esto cerrará #970.

@dsherry ¡Qué oportuno! Eso me suena bien 😊

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