Cet article est écrit par Tim Hill, Data Standards et Technical Lead à l'Open Data Institute

Dans le cas où il y avait un doute dans l'affaire, la publication du Comité britannique pour les normes dans la vie publique Rapport sur l' intelligence artificielle au sein du gouvernement le 10 Février 2 020 a pris fin complètement: l' apprentissage de la machine a quitté le monde du laboratoire de recherche et en gouvernement. «L'intelligence artificielle - et en particulier l'apprentissage automatique», déclare-t-elle, «transformera la façon dont les organisations du secteur public prennent des décisions et fournissent des services publics».

L'ajout de cette nouvelle technique puissante à la boîte à outils du décideur n'est cependant pas sans risque. À l'adage bien connu selon lequel, pour un homme avec un marteau, tout ressemble à un clou devrait être ajouté un autre dicton, bien connu des scientifiques de données. "Avec quatre paramètres, je peux installer un éléphant", a ironisé le mathématicien John von Neumann. "Avec cinq, je peux lui faire bouger son tronc".

Ne vous inquiétez pas si vous ne comprenez pas la blague: le point de von Neumann est simple. Dans les domaines de données complexes dans lesquels l'apprentissage automatique est généralement utilisé, il est facile d'obtenir des résultats faux - voire absurdes.

Vous trouverez ci-dessous quatre questions cruciales à prendre en compte pour vous assurer que votre utilisation de l'apprentissage automatique ne se limite pas à enfoncer des vis dans les murs avec un marteau configurable de manière quadratique - mais ajoute à la place une valeur et un aperçu uniques à leurs domaines.

Avez-vous la bonne équipe?

Les projets d'apprentissage automatique réussis impliquent plus que de simples experts en ML. Ils nécessitent au minimum:

  • Expertise en apprentissage machine
  • Compétences en génie logiciel
  • Une compréhension approfondie des ensembles de données analysés - comment ils ont été collectés, comment ils sont liés les uns aux autres, comment ils sont traités, etc.
  • Connaissance du domaine
  • Représentation des parties prenantes
  • Compétences en gestion suffisantes pour coordonner tout ce qui précède

Le fait qu'il y ait six points énumérés ci-dessus ne signifie pas nécessairement qu'il doit y avoir six personnes ou équipes distinctes impliquées; mais il faut veiller à ce que chacun de ces rôles soit correctement rempli par des personnes ayant fait leurs preuves dans le domaine. En particulier, il est tentant de supposer que les rôles de ML et d'ingénierie logicielle peuvent être exécutés par les mêmes personnes, simplement parce que les deux impliquent des ordinateurs. Mais en fait, les deux compétences sont distinctes - et s'attendre à ce qu'un spécialiste de l'analyse entreprenne une ingénierie logicielle peut rapidement conduire à un code impossible à maintenir ou pire. De même, la connaissance et la compréhension du domaine général d'une collecte de données spécifique et de sa provenance ne doivent pas être confondues. Il peut arriver que la même personne ou la même équipe possède les deux - mais cela ne peut pas simplement être supposé.

En ce qui concerne la représentation des parties prenantes, rappelez-vous que le grand public doit être considéré comme un "acteur" dans les projets du secteur public. Les questions de parti pris et l'utilisation éthique du BC devront être examinées attentivement; et bien sûr, les principes Nolan s'appliquent partout.

ML peut-il répondre aux questions les plus pertinentes pour votre projet ou domaine avec les données à portée de main?

Cela peut être étonnamment difficile à évaluer, c'est pourquoi il est si important d'avoir la bonne équipe en place avant de commencer à examiner votre domaine et à parcourir vos données: très souvent, pour déterminer le rôle que l'apprentissage automatique peut jouer, il faudra une évaluation experte des deux problème qui doit être résolu et des données disponibles.

En outre, ces deux questions peuvent impliquer une enquête prolongée: le nettoyage des données peut souvent prendre entre 60% et 90% du temps total du projet, et il est utile de voir combien est requis ou possible dès le début. En outre, les projets du secteur public seront souvent strictement réglementés, avec des données dispersées sur plusieurs sites pour des raisons de sécurité et des règles de protection des données et d'anonymisation parfois complexes devant être respectées.

Des précautions doivent être prises pour éviter d'utiliser le machine learning pour le plaisir.

Dans les cas où les données nécessaires sont absentes ou de mauvaise qualité, il peut parfois être utile de penser de manière créative et de voir quels aspects du problème d'apprentissage automatique peuvent encore être utiles pour résoudre. À ce stade, cependant, il faut prendre soin d'éviter d'utiliser ML pour le plaisir: sans une question bien définie, les tentatives de simplement exécuter des algorithmes d'apprentissage automatique communs sur des ensembles de données existants donneront presque certainement des résultats faux et / ou dénués de sens. .

Un test d'intégrité utile pour vérifier l'utilité potentielle du ML est de savoir si vous avez ou non une bonne base de référence pour comparer ses performances. La ligne de base à utiliser dépend du domaine. Les domaines scientifiques et médicaux disposeront souvent d'outils statistiques bien établis pour les tâches prédictives, dont l'exactitude peut servir de comparateur utile pour les résultats du BA; à d'autres moments, une approche plus analytique des données (par exemple, attribuer la classe majoritaire aux tâches de classification) sera appropriée. Si la consultation d'experts en analyse de domaine et de données ne parvient pas à fournir une heuristique de référence utile, vous devrez probablement faire plus de données et d'exploration de domaine avant de vous réengager avec ML. D'un autre côté, si vous avez une ligne de base, mais qu'elle est faible, les chances sont bonnes que le ML puisse l'améliorer considérablement.

Pouvez-vous être agile?

Le mot « agile » est tellement utilisé depuis une décennie qu'il semble souvent dénué de sens: même les organisations les plus sclérotiques prétendent être «agiles» et utiliser des «méthodologies agiles» maintenant.

Mais l'apprentissage automatique les exige vraiment. En particulier dans les premiers stades, l'apprentissage automatique implique des itérations fréquentes et des consultations d'équipe pour identifier les fonctionnalités significatives, affiner les paramètres et développer l'infrastructure. Les premiers résultats peuvent sembler absurdes et des modèles complexes pourraient bien devoir être mis au rebut dans les premières phases. En outre, une implication de la nécessité d'une évaluation experte du problème à ses débuts est qu'il peut s'avérer que l'apprentissage automatique n'est pas la bonne approche en premier lieu. Comme Jurgen Mitsch, analyste principal au NHS Trust du Nottingham University Hospital, il est essentiel que les efforts d'apprentissage automatique `` commencent petit et échouent rapidement '' afin de trouver et d'affiner la bonne approche.

L'apprentissage automatique est une entreprise profondément collaborative

L'une des implications de cela est que les approches d'apprentissage automatique nécessiteront l'adhésion de la haute direction à moyen et à long terme si elles ont de grandes chances de réussir. Si des gains rapides sont nécessaires pour obtenir un financement supplémentaire, alors ML ne sera certainement pas viable. À mesure que la technologie d'apprentissage automatique mûrit et s'intègre de plus en plus dans la culture du secteur public, il peut arriver que les itérations soient accélérées et que les résultats soient garantis. Mais nous n'en sommes pas là pour le moment, et la prévoyance et le soutien à long terme seront nécessaires pour réaliser cette vision.

Développez-vous un vocabulaire partagé?

Comme indiqué ci-dessus, l'apprentissage automatique est une entreprise profondément collaborative, qui implique en outre des personnes profondément spécialisées dans leurs domaines respectifs.

Cela peut parfois rendre la communication difficile - et précisément aux moments où il est le plus important d'être clair. L'analyse de données a un vocabulaire technique vaste et parfois prohibitif, qui peut chevaucher mais n'est pas identique à celui utilisé par les spécialistes des données. Ceci, à son tour, a certains - mais pas beaucoup - de points de contact avec le génie logiciel. Et bien sûr, les experts du domaine auront souvent leur propre jargon, qui peut souvent être impénétrable aux étrangers. Un projet réussi devra surmonter ces obstacles s'il veut donner un aperçu.

La complexité des domaines d'apprentissage automatique garantit presque que tout le monde dans la salle aura des «questions stupides» les uns pour les autres, et s'assurer que celles-ci peuvent être diffusées tôt et souvent est vital pour le succès

Au niveau administratif, cela signifie trouver des outils qui permettent à chaque membre de l'équipe de communiquer et de partager des informations pertinentes de manière asynchrone. De nombreux outils et plates-formes utilisés pour les méthodologies de développement logiciel agiles - par exemple, les cartes Kanban, Jira, Azure DevOps, GitHub, etc. - conviennent à cela, mais une taille unique ne conviendra pas à tous. Prenez le temps d'expérimenter et de jouer avec une variété de technologies pour trouver le mix qui vous convient.

Cependant, tout ne peut ou ne doit pas être fait en ligne. En particulier dans les premiers stades, il est important de tenir des tables rondes plénières assez fréquemment, afin que toute l'équipe puisse établir son vocabulaire partagé le plus rapidement possible. Au cours de ces réunions, il faudra veiller à prévoir suffisamment de temps pour la discussion, la clarification des questions et la paraphrase - et dans un environnement sans jugement et ouvert. La complexité des domaines d' apprentissage automatique garantit presque que tout le monde dans la salle aura des «questions stupides» les uns pour les autres, et s'assurer que celles-ci peuvent être diffusées tôt et souvent est vital pour le succès.

Le point des questions stupides, en outre, s'étend au-delà de l'équipe, dans le «monde réel» où les effets de votre projet doivent être ressentis. Une critique courante de l'apprentissage automatique dans les soins de santé est que ses résultats sont communiqués d'une manière si technique et déroutante qu'ils deviennent inutiles pour les cliniciens.

Si vous ne pouvez pas créer un résumé en anglais simple des décisions qui ont été prises et des techniques qui sont utilisées chaque jour, c'est une bonne indication que votre équipe doit travailler davantage à la création d'un vocabulaire partagé - à la fois pour une meilleure compréhension et pour un impact réel. - Tim Hill

(Crédit photo: Unsplash)