Este es el segundo episodio de nuestra exploración del aprendizaje automático «sin código». en nuestro primer artículopresentamos nuestro conjunto de problemas y discutimos los datos que usaríamos para probar si una herramienta de ML altamente automatizada diseñada para analistas de negocios podría arrojar resultados económicos cercanos a la calidad de métodos más intensivos en código involucrando un poco más de ciencia de datos impulsada por humanos.

Si no has leído este artículo, deberías volver atrás y al menos cepillo. Si está listo, revisemos lo que haríamos con nuestros datos de ataque cardíaco en condiciones de aprendizaje automático «normales» (es decir, con más código) y luego deséchelo todo y presione el botón «fácil».

Como discutimos anteriormente, estamos trabajando con un conjunto de datos de salud cardíaca derivado de un estudio en el Instituto Clínico de Cleveland y el Instituto Húngaro de Cardiología en Budapest (así como en otros lugares cuyos datos descartamos por razones de calidad). Todos estos datos están disponibles en un repositorio creamos en GitHub, pero su forma original es parte del un repositorio de datos mantenido para proyectos de aprendizaje automático por la Universidad de California-Irvine. Estamos usando dos versiones del conjunto de datos: una más pequeña y completa que consta de 303 registros de pacientes de la Clínica Cleveland y una base de datos más grande (597 pacientes) que incorpora datos del Instituto Húngaro pero faltan dos de los tipos de datos de el conjunto más pequeño.

Los dos campos que faltan en los datos húngaros parecen potencialmente importantes, pero los datos de la Clínica Cleveland en sí mismos pueden ser un conjunto demasiado pequeño para algunas aplicaciones de ML, por lo que intentaremos cubrir nuestras bases con ambos.

El plano

Con múltiples conjuntos de datos disponibles para entrenamiento y pruebas, era hora de ponerse a trabajar. Si lo hiciéramos de la forma en que los científicos de datos tienden a hacerlo (y de la forma en que lo intentamos el año pasado), estaríamos haciendo lo siguiente:

1. Divida los datos en un conjunto de entrenamiento y un conjunto de prueba
2. Use datos de entrenamiento con un tipo de algoritmo existente para construir el modelo
3. Valide el modelo con el conjunto de pruebas para verificar su precisión

Podríamos hacer todo esto codificándolo en un cuaderno Jupyter y ajustando el modelo hasta que alcancemos una precisión aceptable (como hicimos el año pasado, en un ciclo perpetuo). Pero en cambio, primero probaremos dos enfoques diferentes:

• Un enfoque «sin código» que utiliza Sagemaker Canvas de AWS: Canvas toma los datos como un todo, los desglosa automáticamente en entrenamiento y prueba, y genera un algoritmo predictivo
• Otro enfoque de «código bajo/sin código» usando Sagemaker Studio Jumpstart y AutoML: AutoML es una gran parte de lo que hay detrás de Canvas; evalúa los datos y prueba muchos tipos diferentes de algoritmos para determinar cuál es el mejor

Después de eso, intentemos usar uno de los muchos enfoques de ML probados en batalla que los científicos de datos han probado con este conjunto de datos, algunos de los cuales han afirmado tener una precisión superior al 90%.

El producto final de estos enfoques debería ser un algoritmo que podamos usar para ejecutar una consulta predictiva basada en los puntos de datos. Pero el resultado real será un análisis de las ventajas y desventajas de cada enfoque en términos de tiempo de finalización, precisión y costo del tiempo de cálculo. (En nuestra última prueba, AutoML prácticamente destruyó todo nuestro presupuesto de crédito de cómputo de AWS).