Evalml: API de verificación de datos

detectar valores atípicos (¿y tal vez eliminarlos opcionalmente?)

¿Aplicación de mantas barandillas frente a barandillas de modelo o problema específico?

Estoy reutilizando esta epopeya para referirme al proyecto de API de verificación de datos (anteriormente conocido como "API de Guard Rails").

@ angela97lin , @ kmax12 y yo nos acabamos de reunir para discutir qué hacer con este proyecto. Decidimos:

• Cambiar el alcance del proyecto
  
  
  
  • Diseñe una API para especificar verificaciones de datos, que dan como resultado errores / advertencias
  
  
  • Tomar medidas basadas en esos errores / advertencias está fuera de alcance por ahora, y probablemente será un proyecto en el futuro.
  
  
• Cambie el nombre de "Guard Rails" a "Data Check", porque creemos que es más descriptivo.
• @ angela97lin archivará el documento de diseño de barandillas antiguas y creará uno nuevo con el nuevo alcance

@ angela97lin Acabo de terminar de el nuevo documento de diseño . ¡Buen material! Se ve increíble.

Dejé algunos comentarios y sugerencias, pero desde mi perspectiva, ¡esto está listo para su implementación! Emocionante 👏

Creo que una vez que haya tenido la oportunidad de revisar mis comentarios, el siguiente paso debería ser crear un problema para cada tarea en el plan de implementación y adjuntarlos a esta epopeya. También limpiemos los problemas existentes actualmente en esta epopeya. A primera vista, creo que podemos moverlos a la nevera o cerrarlos.

@ angela97lin y yo acabamos de revisar el nuevo documento de diseño una vez más y arreglamos un par de detalles de diseño. Igual que antes: el siguiente paso es crear problemas y adjuntarlos a esta epopeya. ¡Muy genial!

De # 509:

No queremos que la gente use "mean" / "median" como impute_strategy para los tipos de cadenas. ¿Podría ser bueno agregar algún tipo de verificación de datos para dar cuenta de esto?

Desde # 504: mueva _check_multiclass a una verificación de datos :)

@ angela97lin y yo acabamos de revisar el diseño nuevamente e hicimos algunos ajustes finales. Actualizamos el plan de implementación (actualmente con un alcance de 4 semanas en total) y presentamos problemas adjuntos a esta epopeya.

¡Este proyecto está listo para su implementación!

@ angela97lin va a comenzar este proyecto el lunes. Nuestra fecha de finalización prevista es el lunes 25 de mayo, ¡justo a tiempo para el lanzamiento de mayo de 2020!

También limpiamos los viejos problemas de esta epopeya. Algunos fueron arrancados a la caja de hielo como características futuras, y otros (errores que serán corregidos mediante verificaciones de datos) se marcaron como bloqueados en esta epopeya.

@ angela97lin y yo acabamos de discutir: no incluimos en el diseño ninguna forma de obtener los resultados de la verificación de datos para los usuarios que usan la búsqueda automática directamente (en Python).

Discutimos dos opciones para eso:
1) Haga que AutoSearchBase.search devuelva algo como {'status': 'complete'} , luego, si las comprobaciones de datos fallan, podemos incluir {'status': 'error', 'data_checks': [..]}
2) Haga que AutoSearchBase.search guarde los resultados internamente y exponga un latest_data_check_results getter (no pretende ser el nombre final) para obtenerlos. Luego, genere una excepción para indicar claramente que hubo un problema.

Nos gusta más la segunda opción, así que vamos con eso. Se siente más en línea con nuestros patrones de diseño existentes de a) excepciones sobre códigos de error yb) hacer que los objetos AutoSearchBase sean contenedores para el estado en lugar de objetos de uso único.

Aquí hay un código que simulamos durante la llamada, destinado a ir en AutoSearchBase.search justo antes del bucle principal while que ejecuta la búsqueda real:

        data_check_results = checks.validate(X, y)
        # option 1
        if len(data_check_results) > 0:
            logger.error('Data checks found problems')
            return {'status': 'error', 'data_check_results': data_check_results}
        # option 2
        if len(data_check_results) > 0:
            logger.error('Data checks found problems')
            self._latest_data_check_results = data_check_results
            raise SearchException('One or more data checks failed. Look at latest_data_check_results')

        <strong i="20">@property</strong>
        def latest_data_check_results(self):
            return self._latest_data_check_results

@ angela97lin : nuestro plan actual es hacer el lanzamiento de mayo dentro de una semana. ¿Crees que seremos capaces de fusionar los números 709 y 370 a tiempo para eso? Si no es así, ¿cuánto tiempo cree que se necesita? Podemos enviar fácilmente el n. ° 710 a la próxima versión.

¡@ angela97lin fusionó la mayor parte de esto en el lanzamiento de mayo! El único problema que queda es el # 710. Entonces, cerrando esta épica 🎉