Mes modèles ont échoué. C’est ainsi que je suis devenu un meilleur data scientist.

Le premier modèle prédictif dans le domaine des soins de santé ressemblait à un coup de circuit.

Cela répondait à la question commerciale. Les indicateurs de performance étaient solides. La logique était claire.

La production aurait également connu un échec spectaculaire.

Cette leçon a changé ma façon de penser la science des données et ce qu’il faut pour réussir dans le domaine des soins de santé à l’ère de l’IA.

Avec le recul, cet échec se répétera tout au long de ma carrière, mais il a été crucial pour ma croissance et ma réussite en tant que data scientist : un modèle complexe dans un cahier ne vaut rien si vous ne comprenez pas l’environnement auquel votre modèle est destiné.

Analyste de données

Après trois mois épuisants à chercher mon premier emploi dans le monde réel, dans un marché avec un nouvel appétit pour les données mais qui regorgeait aussi de talents, j’ai enfin eu ma première grande chance. J’ai décroché un poste d’analyste de données débutant au sein de l’équipe de Business Intelligence d’un grand système hospitalier. Il y avait tellement de choses à apprendre. Un obstacle de taille, et que de nombreuses personnes souhaitant se lancer dans le domaine des données de santé devront également franchir, a été de me familiariser avec les tenants et les aboutissants d’Epic, le plus grand fournisseur de DSE (dossier de santé électronique) en termes de part de marché. Se dégourdir les jambes en SQL avec les données extrêmement complexes d’un DSE n’était pas une mince affaire. Pendant les premiers mois, je m’appuyais sur mes collègues seniors pour écrire le code SQL dont j’aurais besoin pour l’analyse. Cela m’a frustré; comment pourrais-je venir de terminer une maîtrise en statistiques et avoir encore du mal à adopter la mentalité SQL ?

Eh bien, avec de la pratique (beaucoup de pratique) et de la patience de mes collègues (beaucoup de patience), tout a finalement commencé à prendre un sens dans ma tête. Au fur et à mesure que mon confort grandissait, je me suis plongé dans le monde de Tableau et des tableaux de bord. Je suis devenu fasciné par le processus de création de tableaux de bord esthétiques qui racontaient des histoires de données qui avaient désespérément besoin d’être racontées.

Tout au long de ma première année, ma responsable m’a été extrêmement solidaire, me vérifiant régulièrement et me demandant quels étaient mes objectifs de carrière et comment elle pouvait m’aider à les atteindre. Elle savait que mon parcours scolaire était plus technique que les analyses ad hoc que je faisais en tant qu’analyste de données débutant, et que je voulais créer des modèles prédictifs. Dans une fin douce-amère de mon premier chapitre, elle m’a proposé de me transférer dans une autre équipe pour me faire vivre cette expérience. Cette équipe était l’équipe Advanced Analytics. Et j’allais devenir Data Scientist.

Scientifique des données I

Dès le premier jour, j’ai travaillé en étroite collaboration avec un gourou de la science des données qui possédait une connaissance approfondie des soins de santé et les capacités techniques correspondantes, lui donnant la capacité de fournir des produits incroyables et d’ouvrir la voie à notre petite équipe. Il a été le premier de notre système à développer un modèle prédictif personnalisé et à le mettre en œuvre dans l’environnement de production, produisant ainsi des scores sur les patients en temps réel. Ces scores étaient utilisés dans les flux de travail cliniques. Lorsque mon manager m’a demandé quels étaient mes objectifs professionnels pour l’année à venir, j’ai eu une réponse immédiate et certaine : je souhaitais mettre en production un modèle prédictif personnalisé.

J’ai commencé par quelques POC (Proofs of Concept). Mon premier modèle était un modèle de régression logistique linéaire qui tentait de prédire la probabilité de complications liées au diabète. Bien qu’il s’agisse d’une bonne première tentative, mon approche d’échantillonnage des données était totalement fausse, et lors de l’examen par les pairs, mon collègue l’a souligné. L’une des principales leçons que j’ai tirées de ma première tentative de modèle prédictif dans le domaine des soins de santé était

Lors de la collecte de données pour former un modèle prédictif, il est essentiel d’imiter les conditions, le contexte du patient et le flux de travail dans lequel le modèle sera utilisé dans l’environnement de production.

Un exemple de ceci : vous ne pouvez pas simplement rassembler les valeurs de laboratoire actuelles de chaque patient et les utiliser comme fonctionnalités dans votre modèle. Si vous vous attendez à ce que le modèle fasse des prédictions, disons 15 minutes après votre arrivée à l’urgence, vous devez en tenir compte. Ainsi, lorsque vous collectez deux années de données historiques pour former un modèle, vous devez rassembler les valeurs de laboratoire de chaque patient telles qu’elles existaient 15 minutes après leur arrivée, c’est-à-dire au moment de la date et de l’heure de leur prédiction simulée, et non celles que sont ces valeurs de laboratoire aujourd’hui/actuellement. Ne pas le faire crée un modèle qui peut fonctionner mieux dans le POC que dans les environnements de production en temps réel, car vous donnez au modèle l’accès à des données dont il ne disposerait pas au moment de la prédiction, un concept connu sous le nom de fuite de données.

Leçon apprise, j’étais prêt à réessayer. J’ai passé les semaines suivantes à développer un modèle pour prédire les non-présentations aux rendez-vous. J’ai été très intentionnel dans la manière dont j’ai collecté les données, j’ai utilisé un algorithme plus robuste et plus puissant, XGBoost, et je suis de nouveau arrivé à l’étape de l’examen par les pairs. L’AUC (zone sous la courbe des caractéristiques de fonctionnement du récepteur) du modèle était étonnante, se situant dans les 0,9 secondes et dépassant les attentes de tout le monde pour un modèle non présenté hors de l’eau. Je me sentais imparable. Ensuite, tout s’est effondré. Au cours d’une analyse approfondie des performances étonnamment solides, j’ai remarqué que la caractéristique la plus importante était l’heure du rendez-vous prévue. En supprimant cette fonctionnalité, l’AUC est tombée au milieu des 0,5 secondes, ce qui signifie que les prédictions du modèle n’étaient pratiquement pas meilleures que des suppositions aléatoires. Pour enquêter sur ce comportement étrange, j’ai sauté sur SQL. C’était là. Dans la base de données, chaque patient qui ne s’est pas présenté à son rendez-vous avait également un rendez-vous prévu à minuit. Certains traitements de données ont modifié rétrospectivement l’heure de rendez-vous de tous les patients qui n’avaient jamais terminé leur rendez-vous. Cela a donné au modèle une fonctionnalité presque parfaite pour prédire les non-présentations. Chaque fois qu’un patient avait rendez-vous à minuit, le mannequin savait que ce patient ne se présenterait pas. Si ce modèle arrivait en production, il ferait des prédictions des semaines avant les rendez-vous à venir, et il ne disposerait pas de cette fonction magique pour améliorer ses performances. Les fuites de données, mon ennemi juré, étaient de retour pour me hanter. Nous avons essayé pendant des semaines de récupérer les performances en utilisant une ingénierie de fonctionnalités créative, un ensemble de données plus vaste pour la formation, des processus de formation plus intensifs, mais rien n’y fait. Ce modèle n’allait pas réussir et j’avais le cœur brisé.

J’ai finalement atteint mon rythme. Mon premier grand succès de modèle prédictif portait également un nom amusant : le modèle DIVA. DIVA signifie Accès Intraveineux Difficile. Le modèle a été conçu pour informer les infirmières lorsqu’elles pourraient avoir des difficultés à placer des perfusions intraveineuses sur certains patients et qu’elles devraient plutôt contacter l’équipe IV pour le placement. L’objectif était de réduire les tentatives intraveineuses infructueuses, en espérant augmenter la satisfaction des patients et réduire les complications pouvant résulter de tels échecs. Le modèle a bien fonctionné, mais pas d’une manière suspecte. Il a passé l’examen par les pairs et j’ai développé le script pour le déployer en production, un processus beaucoup plus difficile que j’aurais pu l’imaginer. L’équipe IV a adoré son nouvel outil et le modèle était utilisé dans les flux de travail cliniques à travers l’organisation. J’ai atteint mon objectif de mettre un modèle en production et j’étais ravi.

Scientifique des données II

Suite à la mise en œuvre réussie de quelques autres modèles, j’ai été promu Data Scientist II. J’ai continué à développer des modèles prédictifs, mais j’ai également pris le temps de me renseigner sur le monde en constante évolution de l’IA. Bientôt, la demande de solutions d’IA a augmenté. Notre premier projet officiel d’IA était un défi interne au sein d’un département dans lequel nous utilisions des modèles linguistiques pour résumer de manière automatisée les publications financières des sociétés cotées en bourse. Ce projet, comme la plupart des autres projets liés à l’IA, était assez différent du développement de modèles ML typique auquel j’étais habitué, mais la variété a été la bienvenue. J’ai eu tellement de plaisir à plonger dans le monde des processus ETL, des invites efficaces et de l’automatisation. Alors que nous commençons tout juste à nous lancer dans les initiatives d’IA, je suis enthousiasmé par les nouveaux types de problèmes commerciaux pour lesquels nous pouvons désormais créer des solutions.

Mon rôle en tant que data scientist a évolué à mesure que les systèmes d’IA se sont améliorés. Développer des solutions DS/ML et IA nécessite désormais beaucoup moins d’efforts de travail technique, et je me considère presque comme à la fois un scientifique des données et un chef de projet IA pendant le processus. Les systèmes d’IA auxquels nous avons désormais accès peuvent écrire du code, tester des bogues et effectuer des modifications de manière très efficace grâce à des invites tactiques de notre part. Cela dit, l’impact et la faisabilité des initiatives d’IA suscitent une inquiétude croissante, divers rapports suggérant que la plupart des projets d’IA échouent avant d’avoir été mis en production. Je crois

Un Data Scientist doté de solides bases techniques et d’une expertise en la matière peut être le plus grand atout pour lutter contre le taux d’échec élevé des projets d’IA.

Notre compréhension des principes fondamentaux des modèles prédictifs, associée à notre connaissance du domaine au sein de nos secteurs (les soins de santé, dans mon cas), est toujours indispensable pour créer des solutions efficaces et pouvant apporter de la valeur. Il est révolu le temps où nous pouvions compter uniquement sur notre sens technique pour apporter de la valeur. Le codage est désormais géré par les LLM. L’automatisation est beaucoup plus accessible avec les fournisseurs de cloud. Nous avons désormais besoin d’un expert capable de traduire les besoins de l’entreprise en un plan stratégique guidant l’IA vers une solution efficace. Le data scientist moderne est le candidat idéal pour devenir ce traducteur.

Conclusion

La science des données, comme tout cheminement de carrière dans la technologie, est en constante évolution. Comme vous pouvez le voir ci-dessus, mon rôle a tellement changé au cours des années qui ont suivi l’université. J’ai gravi quelques échelons de l’échelle de l’entreprise, passant d’analyste de données débutant à Data Scientist II, et je peux dire avec confiance que les compétences requises pour réussir ont évolué au fil des années et des progrès technologiques ont été réalisés, mais il est important de se souvenir des leçons apprises en cours de route.

Mes modèles ont échoué.

Ces échecs ont façonné ma carrière.

Dans le domaine de la santé, en particulier avec la magie de l’IA à portée de main, un data scientist performant n’est pas celui qui peut créer les modèles les plus complexes.

Un data scientist qui réussit est celui qui comprend l’environnement auquel le modèle est destiné.