Libérer notre IA prédictive des crises cardiaques avec des outils « sans code »

Agrandir / Ahhh, le bouton facile !

Aurich Lawson | Getty Images

Il s’agit du deuxième épisode de notre exploration de l’apprentissage automatique “sans code”. Dans notre premier article, nous avons exposé notre ensemble de problèmes et discuté des données que nous utiliserions pour tester si un outil de ML hautement automatisé conçu pour les analystes commerciaux pouvait renvoyer des résultats rentables proches de la qualité de méthodes plus gourmandes en code impliquant un peu plus d’humain. science des données axée sur les données.

Si vous n’avez pas lu cet article, vous devriez revenir en arrière et au moins le parcourir. Si vous êtes prêt, examinons ce que nous ferions avec nos données sur les crises cardiaques dans des conditions d’apprentissage automatique “normales” (c’est-à-dire plus gourmandes en code), puis jetez tout cela et appuyez sur le bouton “facile”.

Comme nous en avons discuté précédemment, nous travaillons avec un ensemble de données sur la santé cardiaque dérivées d’une étude du Cleveland Clinic Institute et de l’Institut hongrois de cardiologie de Budapest (ainsi que d’autres endroits dont nous avons rejeté les données pour des raisons de qualité). Toutes ces données sont disponibles dans un référentiel que nous avons créé sur GitHub, mais leur forme originale fait partie d’un référentiel de données géré pour les projets d’apprentissage automatique par l’Université de Californie à Irvine. Nous utilisons deux versions de l’ensemble de données : une version plus petite et plus complète composée de 303 dossiers de patients de la clinique de Cleveland et une base de données plus importante (597 patients) qui intègre les données de l’Institut hongrois, mais il manque deux des types de données de le plus petit ensemble.

Les deux champs manquants dans les données hongroises semblent potentiellement conséquents, mais les données de la Cleveland Clinic elles-mêmes peuvent être un ensemble trop petit pour certaines applications ML, nous allons donc essayer les deux pour couvrir nos bases.

Publicité

Le plan

Avec plusieurs ensembles de données en main pour la formation et les tests, il était temps de commencer à moudre. Si nous faisions cela comme le font habituellement les data scientists (et comme nous avons essayé l’année dernière), nous ferions ce qui suit :

1. Diviser les données en un ensemble d’apprentissage et un ensemble de test
2. Utiliser les données d’entraînement avec un type d’algorithme existant pour créer le modèle
3. Valider le modèle avec l’ensemble de test pour vérifier sa précision

Nous pourrions faire tout cela en le codant dans un cahier Jupyter et en peaufinant le modèle jusqu’à ce que nous obtenions une précision acceptable (comme nous l’avons fait l’année dernière, dans un cycle perpétuel). Mais à la place, nous allons d’abord essayer deux approches différentes :

• Une approche « sans code » utilisant AWS SageMaker Canvas : Canvas prend les données dans leur ensemble, les divise automatiquement en formation et en test, et génère un algorithme prédictif
• Une autre approche “sans/faible code” utilisant SageMaker Jumpstart et AutoPilot : AutoML est une grande partie de ce qui se cache derrière Canvas ; il évalue les données et essaie un certain nombre de types d’algorithmes différents pour déterminer ce qui est le mieux

Une fois cela fait, nous allons nous lancer en utilisant l’une des nombreuses approches ML éprouvées que les scientifiques des données ont déjà essayées avec cet ensemble de données, dont certaines ont revendiqué une précision de plus de 90 %.

Le produit final de ces approches devrait être un algorithme que nous pouvons utiliser pour exécuter une requête prédictive basée sur les points de données. Mais le résultat réel sera un aperçu des compromis de chaque approche en termes de temps d’achèvement, de précision et de coût du temps de calcul. (Lors de notre dernier test, AutoPilot lui-même a pratiquement explosé tout notre budget de crédit de calcul AWS.)