Par le laboratoire d'intelligence artificielle de l'Agence canadienne d'inspection des aliments

Introduction

L'équipe du laboratoire d'intelligence artificielle (IA) de l'Agence canadienne d'inspection des aliments (ACIA) est composée d'un groupe diversifié d'experts, y compris des scientifiques des données, des développeurs de logiciels et des chercheurs diplômés, qui travaillent ensemble pour offrir des solutions novatrices pour l'avancement de la société canadienne. En collaborant avec des membres des directions générales interministérielles du gouvernement, le laboratoire d'IA tire parti d'algorithmes d'apprentissage automatique à la fine pointe de la technologie pour offrir des solutions axées sur les données à des problèmes réels et favoriser un changement positif.

Au laboratoire d'IA de l'ACIA, nous exploitons le plein potentiel des modèles d'apprentissage profond. Notre équipe spécialisée de scientifiques des données tire parti de la puissance de cette technologie transformatrice et élabore des solutions personnalisées adaptées aux besoins particuliers de nos clients.

Dans le présent article, nous justifions le recours aux modèles de vision par ordinateur pour la classification automatique des espèces de semences. Nous démontrons de quelle façon nos modèles personnalisés ont permis d'obtenir des résultats prometteurs en utilisant des images de semences « réelles » et nous décrivons nos orientations futures pour le déploiement d'une application SeedID conviviale.

Au laboratoire d'intelligence artificielle de l'ACIA, nous nous efforçons non seulement de repousser les frontières de la science en tirant parti de modèles de pointe, mais aussi en rendant ces services accessibles à d'autres et en favorisant le partage des connaissances, afin de promouvoir l'évolution constante de la société canadienne.

Vision par ordinateur

Pour comprendre le fonctionnement des modèles de classification d'images, nous devons d'abord définir les objectifs visés par la vision par ordinateur.

Qu'est-ce que la vision par ordinateur?

Les modèles de vision par ordinateur tentent essentiellement de résoudre ce qu'on appelle mathématiquement des problèmes mal posés. Les modèles cherchent à répondre à la question suivante : qu'est-ce qui a engendré l'image?

En tant qu'humains, nous faisons cela naturellement. Lorsque les photons pénètrent dans nos yeux, notre cerveau est capable de traiter les différents modèles de lumière, ce qui nous permet d'inférer l'existence du monde physique qui se trouve devant nous. Dans le contexte de la vision par ordinateur, nous essayons de reproduire notre capacité humaine innée de perception visuelle au moyen d'algorithmes mathématiques. Des modèles de vision par ordinateur efficaces pourraient alors être utilisés pour répondre à des questions liées aux tâches suivantes :

• Catégorisation d'objets : la capacité de classer des objets dans une image ou de reconnaître le visage d'une personne dans des images.
• Catégorisation de scènes et de contextes : la capacité à comprendre ce qui se passe dans une image à partir de ses composantes (p. ex. intérieur et extérieur, circulation et absence de circulation).
• Information spatiale qualitative : la capacité de décrire qualitativement des objets dans une image, comme un objet rigide en mouvement (p. ex. autobus), un objet non rigide en mouvement (p. ex. drapeau), un objet vertical, horizontal, incliné, etc.

Pourtant, bien que ces tâches semblent simples, les ordinateurs ont encore des difficultés à interpréter et à comprendre avec précision notre monde complexe.

Pourquoi la vision par ordinateur est-elle si difficile?

Pour comprendre pourquoi les ordinateurs semblent avoir de la difficulté à accomplir ces tâches, nous devons d'abord considérer ce qu'est une image.

Êtes-vous en mesure de décrire cette image à partir de ces valeurs?

Une image est un ensemble de chiffres, avec généralement trois canaux de couleur : rouge, vert, bleu (RVB). Afin de tirer une signification de ces valeurs, l'ordinateur doit effectuer ce que l'on appelle une reconstruction d'image. Dans sa forme la plus simplifiée, nous pouvons exprimer mathématiquement cette idée par une fonction inverse :

x = F-1(y)

où :

y représente les mesures des données (c.-à-d. les valeurs des pixels);
x représente une version reconstruite des mesures, y, dans une image.

Cependant, il s'avère que la résolution de ce problème inverse est plus difficile que prévu en raison de la nature « mal posée » du problème.

Qu'est-ce qu'un problème mal posé?

Lorsqu'une image est enregistrée, il se produit une perte inhérente de renseignements puisque le monde en 3D est projeté sur un plan en 2D. Même pour nous, la compression de l'information spatiale que nous recueillons du monde physique peut rendre difficile de distinguer ce que nous voyons sur les photos.

Michel-Ange (1475-1564). L'occlusion causée par les différents points de vue peut rendre difficile la reconnaissance d'une même personne.

Fond de canettes de soda. Des orientations différentes peuvent rendre impossible l'identification du contenu de la canette.

Base de données des visages de Yale. Les variations d'éclairage peuvent rendre difficile la reconnaissance d'une même personne (rappel : tout ce que les ordinateurs « voient », ce sont des valeurs de pixels).

Rick Scuteri-USA TODAY Sports. Des échelles différentes peuvent rendre difficile la compréhension du contexte des images.

Différentes photos de chaises. La variation entre les catégories peut rendre difficile la catégorisation des objets (nous pouvons discerner une chaise grâce à son aspect fonctionnel).

Il peut être difficile de reconnaître des objets dans des images 2D en raison d'éventuelles propriétés mal posées, notamment :

• Manque d'unicité : Plusieurs objets peuvent donner lieu à la même mesure.
• Incertitude : Le bruit (p. ex. le flou, la pixillation, les dommages physiques) dans les photos peut rendre difficile, voire impossible, la reconstitution et la reconnaissance d'une image.
• Incohérence : de légers changements dans les images (p. ex. différents points de vue, différents éclairages, différentes échelles) peuvent rendre complexe le fait de trouver la solution « x » à partir des points de données disponibles « y »

Si les tâches de vision par ordinateur peuvent, à première vue, sembler superficielles, le problème sous-jacent qu'elles tentent de résoudre est très complexe!

Nous allons maintenant nous pencher sur certaines solutions axées sur l'apprentissage profond pour résoudre les problèmes de vision par ordinateur.

Réseaux neuronaux convolutifs (RNC)

Représentation graphique d'une architecture de réseau neuronal convolutif (RNC) pour la reconnaissance d'images. (Hoeser and Kuenzer, 2020 (en anglais seulement))

La couche de sous-échantillonnage réduit la taille de l'image en appliquant une opération de sous-échantillonnage à la sortie de la couche convolutive. La couche de sortie traite l'image et produit un résultat final. Le réseau est entraîné à l'aide d'un ensemble de données d'images et de leurs étiquettes correspondantes.

Les réseaux neuronaux convolutifs (RNC) sont un type d'algorithme qui s'est avéré très efficace pour résoudre de nombreux problèmes de vision par ordinateur, comme nous l'avons décrit précédemment. Afin de classer ou d'identifier des objets dans des images, un modèle RNC apprend d'abord à reconnaître des caractéristiques simples dans les images, telles que les contours, les coins et les textures. Pour ce faire, il applique différents filtres à l'image. Ces filtres aident le réseau à se concentrer sur des motifs précis. Au fur et à mesure de son apprentissage, le modèle commence à reconnaître des caractéristiques plus complexes et combine les caractéristiques simples apprises à l'étape précédente pour créer des représentations plus abstraites et plus significatives. Enfin, le RNC utilise les caractéristiques apprises précédemment pour classer les images en fonction des classes avec lesquelles il a été entraîné.

Évolution des architectures RNC et de leur précision pour les tâches de reconnaissance d'images entre 2012 et 2019. (Hoeser and Kuenzer, 2020 (en anglais seulement)).

Le premier RNC a été proposé par Yann LeCun en 1989 (LeCun, 1989 (en anglais seulement)) pour la reconnaissance des chiffres manuscrits. Depuis lors, les RNC ont évolué de manière importante au fil des ans, grâce aux progrès réalisés à la fois dans l'architecture des modèles et dans la puissance informatique disponible. Aujourd'hui encore, les RNC continuent de faire leurs preuves en tant qu'architectures puissantes pour diverses tâches de reconnaissance et d'analyse de données.

Transformateurs de vision (ViT)

Les transformateurs de vision (ViT) relèvent d'un développement récent dans le domaine de la vision par ordinateur qui applique aux données visuelles le concept des transformateurs, conçu à l'origine pour les tâches de traitement du langage naturel. Au lieu de traiter une image comme un objet en 2D, les transformateurs de vision la considèrent comme une séquence de « cases », de la même manière que les transformateurs traitent une phrase comme une séquence de mots.

Vue d'ensemble d'un transformateur de vision comme illustré dans Une image vaut 16x16 mots : Transformateurs pour la reconnaissance d'images à l'échelle (en anglais seulement). Depuis la publication du transformateur de vision original, de nombreuses variations et de nombreuses variétés ont été proposées et étudiées.

Le processus commence par la division d'une image en une grille de cases. Chaque case est ensuite aplatie en une séquence de vecteurs de pixels. Des codages de position sont ajoutés pour conserver les renseignements sur la position, comme le font les transformateurs pour les tâches linguistiques. L'entrée transformée est ensuite traitée au moyen de plusieurs couches d'encodeurs du transformateur pour créer un modèle capable de comprendre des données visuelles complexes.

Tout comme les réseaux neuronaux convolutifs (RNC) apprennent à identifier les modèles et les caractéristiques d'une image par l'entremise des différentes couches convolutives, les transformateurs de vision identifient les modèles en se concentrant sur les relations entre les cases d'une image. Ils apprennent essentiellement à évaluer l'importance des différentes cases par rapport aux autres afin d'établir des classifications précises. Le modèle ViT a été présenté pour la première fois par l'équipe de Google Brain dans un article publié en 2020. Bien que les RNC aient dominé le domaine de la vision par ordinateur pendant des années, l'introduction des transformateurs de vision a démontré que les méthodes mises au point pour le traitement du langage naturel pouvaient également être utilisées pour des tâches de classification d'images, souvent avec des résultats supérieurs.

L'un des principaux avantages des transformateurs de vision est que, contrairement aux RNC, ils ne reposent pas sur une hypothèse intégrée de localité spatiale et d'invariance de décalage. Cela signifie qu'ils sont mieux adaptés aux tâches nécessitant une compréhension globale d'une image, ou lorsque de légers décalages peuvent modifier radicalement la signification d'une image.

Cependant, les ViT nécessitent généralement une plus grande quantité de données et de ressources de calcul que les RNC. Ce facteur a conduit à une tendance de modèles hybrides qui combinent à la fois les RNC et les transformateurs afin d'exploiter les forces des deux architectures.

Classification des semences

Contexte :

L'industrie des semences et des céréales du Canada, qui représente plusieurs milliards de dollars, s'est taillé une réputation mondiale en ce qui concerne la production, la transformation et l'exportation de semences de qualité supérieure pour la plantation ou de céréales destinées à l'alimentation dans une vaste gamme de cultures. Son succès est attribuable à l'engagement du Canada en faveur de l'innovation et du développement de technologies de pointe, ce qui lui permet de fournir des produits de haute qualité conformes aux normes nationales et internationales, avec une certification diagnostique qui répond aux besoins nationaux et internationaux.

Naturellement, une collaboration entre une équipe de recherche du Centre pour la science et la technologie des semences et du laboratoire d'intelligence artificielle de l'ACIA a été mise en place pour maintenir le rôle du Canada en tant que chef de file de renom dans le secteur mondial des semences ou des céréales et dans les industries de mise à l'essai connexes.

Contexte : Contrôle de la qualité

La qualité des semences d'une culture est consignée dans un rapport de classement. La catégorie finale indique dans quelle mesure un lot de semences satisfait aux normes de qualité minimales, conformément au Règlement sur les semences du Canada. Les facteurs utilisés pour déterminer la qualité des cultures comprennent les graines de mauvaises herbes contaminées, conformément à l'Arrêté sur les graines de mauvaises herbes du Canada, l'analyse de la pureté, ainsi que la germination et les maladies. Bien que la germination offre un potentiel de rendement au champ, il est essentiel d'évaluer la pureté physique de la plante pour s'assurer qu'elle contient une grande quantité des semences désirées et qu'elle est exempte de contaminants, comme des espèces interdites et réglementées, des semences de culture différente ou des graines de mauvaises herbes différentes. L'inspection des semences joue un rôle important dans la prévention de la propagation des espèces interdites et réglementées énumérées dans l'Arrêté sur les graines de mauvaises herbes. Le Canada est l'une des plus importantes bases de production pour l'approvisionnement alimentaire mondial, exportant un grand nombre de céréales comme le blé, le canola, les lentilles et le lin. Pour satisfaire à l'exigence de certification phytosanitaire et avoir accès à de vastes marchés étrangers, l'analyse des semences de mauvaises herbes réglementées pour les destinations d'importation est en forte demande, avec un délai d'exécution rapide et des changements fréquents. La capacité de contrôle pour la détection des graines de mauvaises herbes nécessite le soutien de technologies de pointe, car les méthodes traditionnelles font face à un grand défi en raison de la demande.

Justification

À l'heure actuelle, l'évaluation de la qualité d'une culture est effectuée manuellement par des experts humains. Cependant, ce processus est fastidieux et prend beaucoup de temps. Au laboratoire d'IA, nous tirons parti de modèles de vision par ordinateur avancés pour classer automatiquement les espèces de semences à partir d'images, ce qui rend ce processus plus efficace et plus fiable.

Ce projet vise à développer et à déployer un puissant pipeline de vision par ordinateur pour la classification des espèces de semences. En automatisant ce processus de classification, nous pouvons simplifier et accélérer l'évaluation de la qualité des cultures. Nous développons des solutions fondées sur des algorithmes avancés et des techniques d'apprentissage profond, tout en assurant une évaluation impartiale et efficace de la qualité des cultures, ouvrant ainsi la voie à l'amélioration des pratiques agricoles.

Projet no 1 : Imagerie et analyse multispectrales

Dans le cadre de ce projet, nous utilisons un modèle de vision par ordinateur personnalisé pour évaluer la pureté du contenu, en déterminant et en classifiant les espèces de semences désirées pour les distinguer des espèces de semences non désirées.

Nous parvenons à récupérer et à déterminer les cas de contamination par trois espèces de mauvaises herbes différentes dans un mélange trié d'échantillons de blé.

Notre modèle est personnalisé de manière à accepter des entrées d'images multispectrales uniques à haute résolution à 19 canaux et à atteindre une précision de plus de 95 % sur les données d'essai.

Nous avons exploré plus en profondeur le potentiel de notre modèle à classer de nouvelles espèces, en introduisant cinq nouvelles espèces de canola dans l'ensemble de données et en observant des résultats similaires. Ces résultats encourageants mettent en évidence le potentiel d'utilisation continue de notre modèle, même lorsque de nouvelles espèces de semences sont introduites.

Notre modèle a été formé pour classer les espèces suivantes :

1. Trois espèces différentes de chardon (mauvaises herbes) :
   1. Cirsium arvense (espèces réglementées)
   2. Carduus nutans (semblables aux espèces réglementées)
   3. Cirsium vulgare (semblables aux espèces réglementées)
2. Six semences de culture :
   1. Triticum aestivum, sous-espèce aestivum
   2. Brassica napus, sous-espèce napus
   3. Brassica juncea
   4. Brassica juncea (de type jaune)
   5. Brassica rapa, sous-espèce oleifera
   6. Brassica rapa, sous-espèce oleifera (de type brun)

Notre modèle a permis d'identifier correctement chaque espèce de semence avec une précision de plus de 95 %.

De plus, lorsque les semences des trois espèces différentes de chardon ont été intégrées au criblage du blé, le modèle a atteint une précision moyenne de 99,64 % sur 360 semences. Ces résultats ont permis de démontrer la robustesse du modèle et sa capacité à classer de nouvelles images.

Enfin, nous avons introduit cinq nouveaux types et espèces de canola et évalué le rendement de notre modèle. Les résultats préliminaires de cette expérience ont montré une précision d'environ 93 % sur les données de test.

Projet no 2 : Imagerie et analyse en mode RVB au microscope numérique

Dans le cadre de ce projet, nous utilisons un processus en deux étapes pour déterminer un total de 15 espèces de semences différentes ayant une importance réglementaire et présentant un défi morphologique à divers niveaux de grossissement.

Tout d'abord, un modèle de segmentation des semences est utilisé pour déterminer chaque instance d'une semence dans l'image. Ensuite, un modèle de classification permet de classer chaque espèce de semence.

Nous réalisons plusieurs études par ablation en entraînant le modèle sur un profil de grossissement, puis en le testant sur des images de semences provenant d'un autre ensemble d'images à divers niveaux de grossissement. Nous obtenons des résultats préliminaires prometteurs d'une précision de plus de 90 % pour tous les niveaux de grossissement.

Trois niveaux de grossissement différents ont été fournis pour les 15 espèces suivantes :

1. Ambrosia artemisiifolia
2. Ambrosia trifida
3. Ambrosia psilostachya
4. Brassica junsea
5. Brassica napus
6. Bromus hordeaceus
7. Bromus japonicus
8. Bromus secalinus
9. Carduus nutans
10. Cirsium arvense
11. Cirsium vulgare
12. Lolium temulentum
13. Solanum carolinense
14. Solanum nigrum
15. Solanum rostratum

Un mélange de 15 espèces différentes a été pris en photo à différents niveaux de grossissement. Le niveau de grossissement a été indiqué par le nombre total d'occurrences de semences présentes dans l'image, soit : 1, 2, 6, 8 ou 15 semences par image.

Afin d'établir un protocole d'enregistrement d'image normalisé, nous avons entraîné de manière indépendante des modèles distincts à partir d'un sous-ensemble de données à chaque niveau de grossissement, puis nous avons évalué le rendement du modèle sur un ensemble de données de test réservé à tous les niveaux de grossissement.

Les résultats préliminaires ont démontré la capacité du modèle à déterminer correctement les espèces de semences à différents niveaux de grossissement avec une précision de plus de 90 %.

Ces résultats ont permis de révéler le potentiel du modèle à classer avec précision des données jusque-là inconnues à différents niveaux de grossissement.

Tout au long de nos expériences, nous avons essayé et testé différentes méthodologies et différents modèles.

Les modèles avancés équipés d'une forme canonique comme les transformateurs « Swin » ont mieux résisté et se sont révélés moins perturbés par le niveau de grossissement et de zoom.

Discussion et défis

La classification automatique des semences est une tâche difficile. L'entraînement d'un modèle d'apprentissage automatique pour la classification des semences pose plusieurs défis en raison de l'hétérogénéité inhérente aux différentes espèces et entre celles-ci. Par conséquent, de grands ensembles de données sont nécessaires pour entraîner efficacement un modèle à l'apprentissage de caractéristiques propres à une espèce. De plus, le degré élevé de ressemblance entre différentes espèces au sein des genres pour certaines d'entre elles rend difficile, même pour des experts humains, la distinction entre des espèces intragenres étroitement apparentées. De plus, la qualité de la capture d'images peut également avoir une incidence sur le rendement des modèles de classification des semences, car les images de faible qualité peuvent entraîner la perte de renseignements importants nécessaires à une classification précise.

Pour relever ces défis et améliorer la robustesse des modèles, des techniques d'enrichissement des données ont été appliquées dans le cadre des étapes de prétraitement. Les transformations affines, comme la mise à l'échelle et la traduction d'images, ont été utilisées pour augmenter la taille de l'échantillon, tandis que l'ajout de bruit gaussien peut augmenter la variation et améliorer la généralisation sur les données non encore vues par le modèle, empêchant ainsi le surapprentissage sur les données d'entraînement.

Le choix de l'architecture de modèle appropriée a été crucial pour atteindre le résultat souhaité. Un modèle peut ne pas produire de résultats exacts si les utilisateurs finaux ne respectent pas un protocole normalisé, particulièrement lorsque les données fournies ne correspondent pas à la distribution prévue. Par conséquent, il était impératif de tenir compte de diverses sources de données et d'utiliser un modèle qui fait montre d'une capacité de généralisation efficace entre domaines pour assurer une classification exacte des semences.

Conclusion

Le projet de classification des semences est un exemple de la collaboration fructueuse et continue entre le laboratoire d'IA et le Centre pour la science et la technologie des semences de l'ACIA. En mettant en commun leurs connaissances et leur expertise respectives, les deux équipes contribuent à l'avancement des industries des semences et des céréales du Canada. Le projet de classification des semences montre de quelle façon l'utilisation d'outils avancés d'apprentissage automatique peut améliorer considérablement l'exactitude et l'efficacité de l'évaluation de la qualité des semences ou des céréales en conformité avec le Règlement sur la protection des semences ou le Règlement sur la protection des végétaux, au plus grand bénéfice du secteur agricole, des consommateurs, de la biosécurité et de la salubrité des aliments.

En tant que scientifiques des données, nous reconnaissons l'importance de la collaboration ouverte et nous sommes déterminés à respecter les principes de la science ouverte. Notre objectif est de promouvoir la transparence et la mobilisation grâce à un libre échange avec le public.

En rendant notre application accessible, nous invitons les autres chercheurs, les experts en semences et les développeurs à contribuer à son amélioration et à sa personnalisation. Cette approche collaborative favorise l'innovation, ce qui permet à la communauté d'améliorer collectivement les capacités de l'application SeedID et de répondre aux exigences particulières de différents domaines.

Abonnez-vous au bulletin d'information du Réseau de la science des données pour la fonction publique fédérale pour rester au fait des dernières nouvelles de la science des données.

Par David Chiumera, Statistique Canada

Au cours des dernières années, le domaine de la science des données a connu une croissance explosive puisque les entreprises de nombreux secteurs investissent massivement dans des solutions fondées sur les données afin d’optimiser les processus de prise de décision. Cependant, le succès de tout projet de science des données dépend fortement de la qualité du code en arrière-plan. L’écriture du code de niveau de production est essentielle pour veiller à ce que les modèles et les applications de la science des données soient mis en œuvre et appliqués efficacement, permettant ainsi aux entreprises de réaliser la pleine valeur de leur investissement dans la science des données.

Le code de niveau de production correspond à un code conçu pour satisfaire les besoins d’un utilisateur final, l’accent étant mis sur l’extensibilité, la robustesse et la maintenabilité. Cela contraste avec le code écrit uniquement à des fins d’expérimentation et d’exploration, qui peut ne pas être optimisé en vue d’être utilisé dans l’environnement de production. L’écriture du code de niveau de production est essentielle pour les projets en science des données, car elle permet le déploiement efficace de solutions dans des environnements de production, où ils peuvent être intégrés à d’autres systèmes et utilisés pour éclairer la prise de décision.

Le code de niveau de production présente plusieurs avantages clés pour les projets en science des données. Tout d’abord, il garantit que les solutions de science des données peuvent être facilement déployés et appliqués. Deuxièmement, il réduit le risque d’erreurs, de vulnérabilités et de temps d’arrêt. Enfin, il facilite la collaboration entre les scientifiques des données et les réalisateurs de logiciels, ce qui leur permet de travailler ensemble plus efficacement pour fournir des solutions de haute qualité. Enfin, il favorise la réutilisation du code et la transparence, ce qui permet aux scientifiques des données d’échanger leurs travaux avec d’autres et de s’appuyer sur le code existant pour améliorer les projets à venir.

Dans l’ensemble, le code de niveau de production est un élément essentiel de tout projet de science des données réussi. En accordant la priorité au développement d’un code qui est de haute qualité, évolutif et maintenable, les entreprises peuvent ainsi assurer l’optimisation de leur investissement dans la science des données, prendre des décisions plus éclairées et acquérir un avantage concurrentiel dans l’économie actuelle axée sur les données.

La portée de la science des données et ses différentes applications

Le champ d’application de la science des données est vaste; il englobe un large éventail de techniques et d’outils utilisés pour tirer des connaissances à partir de données. À la base, la science des données comprend la collecte, l’épuration et l’analyse des données afin de cerner les tendances et de faire des prédictions. Ses applications sont nombreuses, allant de l’intelligence économique et de l’analyse marketing jusqu’aux soins de santé et à la recherche scientifique. La science des données est utilisée pour résoudre un large éventail de problèmes, comme la prédiction du comportement des consommateurs, la détection de la fraude, l’optimisation des activités et l’amélioration des résultats des soins de santé. Comme la quantité de données générées continue de croître, le champ d’application de la science des données devrait aussi continuer de s’étendre, en mettant de plus en plus l’accent sur l’utilisation de techniques avancées comme l’apprentissage automatique et l’intelligence artificielle.

Pratiques de programmation et de génie logiciel appropriées pour les scientifiques des données

Des pratiques de programmation et de génie logiciel appropriées sont essentielles pour créer des applications de science des données robustes qui peuvent être déployées et tenues à jour efficacement. Les applications robustes sont celles qui sont fiables, évolutives et efficaces et qui répondent aux besoins de l’utilisateur final. Plusieurs types de pratiques de programmation et de génie logiciel sont particulièrement importants dans le contexte de la science des données, comme le contrôle de version, les tests automatisés, la documentation, la sécurité, l’optimisation du code et l’usage adéquat des modèles de conception, pour n’en citer que quelques-uns.

En suivant les bonnes pratiques, les scientifiques des données peuvent créer des applications robustes qui sont fiables, évolutives et efficaces, tout en mettant l’accent sur les besoins de l’utilisateur final. Cela est essentiel pour garantir que les solutions de la science des données apportent une valeur optimale aux entreprises et aux autres organismes.

Projet de prétraitement des données administratives et son objectif : un exemple

Le projet de prétraitement des données administratives (PDA) est une application du secteur 7 qui nécessite la participation de la Division de la science des données pour réusiner une composante élaborée par un citoyen en raison de divers problèmes qui nuisaient à son état de préparation pour l’environnement de production. Plus précisément, la base du code utilisée pour intégrer les flux de travail externes au système ne respectait pas les pratiques de programmation établies, ce qui se traduisait par une expérience utilisateur lourde et difficile. De plus, on remarque une absence notable de rétroaction pertinente de la part du programme lorsqu’il y a une défaillance, ce qui fait en sorte qu’il est difficile de diagnostiquer et de régler les problèmes.

On a aussi constaté des lacunes dans la base de code en ce qui a trait à la documentation, à la journalisation des erreurs et aux messages d’erreur significatifs pour les utilisateurs, ce qui a encore aggravé le problème. Le couplage dans la base de code était excessif, ce qui fait en sorte qu’il a été difficile de modifier ou d’étendre des fonctions du programme, au besoin. De plus, il n’y avait aucun essai unitaire en place pour assurer la fiabilité et l’exactitude. En outre, le code était trop adapté à un exemple précis. Il était donc difficile de l’appliquer d’une façon générale à d’autres scénarios d’utilisation. Il y avait aussi plusieurs caractéristiques souhaitées qui n’étaient pas présentes pour satisfaire les besoins du client.

Ces problèmes nuisaient grandement à la capacité du projet de PDA d’effectuer le prétraitement de données semi-structurées. L’absence de rétroaction et de documentation a fait en sorte qu’il était extrêmement difficile, voire impossible, pour le client d’utiliser efficacement les flux de travail intégrés, ce qui a donné lieu à de la frustration et à des inefficacités. Souvent, les résultats du programme n’étaient pas conformes aux attentes, et l’absence d’essais unitaires ne permettait pas de garantir la fiabilité et la précision. En résumé, le projet de PDA nécessitait le réusinage des flux de travail intégrés (c.-à-d. l’épuration ou le remaniement du code). Ce processus à multiples facettes comprenait le règlement d’un éventail de problèmes de programmation et d’ingénierie pour que l’application soit plus robuste et prête pour l’environnement de production. Pour ce faire, nous avons utilisé une approche de réusinage « Rouge-Vert » pour améliorer la qualité du produit.

Réusinage à l’aide d’une approche « Rouge-Vert » au lieu d’une approche « Vert-Rouge »

Le réusinage est le processus de remaniement du code existant en vue d’en améliorer la qualité, la lisibilité, la maintenance et le rendement. Cela peut nécessiter diverses activités, y compris l’épuration du formatage du code, l’élimination des codes en double, l’amélioration des conventions de dénomination et l’introduction de nouvelles abstractions et de nouveaux modèles de conception.

Le réusinage est avantageux pour diverses raisons. Premièrement, cette approche peut améliorer la qualité globale de la base de code, ce qui facilite la compréhension et la maintenance. Cela permet d’économiser du temps et des efforts à long terme, surtout lorsque les bases de code deviennent plus grandes et plus complexes. De plus, le réusinage peut améliorer la performance et réduire les risques de bogues et d’erreurs, ce qui se traduit par une application plus fiable et robuste.

Une approche courante de réusinage est l’approche « Rouge-Vert », qui fait partie du processus de développement basé sur les tests. Dans l’approche Rouge-Vert, un scénario d’essai défaillant est écrit avant que le code ne soit écrit ou réusiné. À la suite de ce test défaillant, on procède à l’écriture du code minimal qui serait requis pour obtenir un test réussi, après quoi on réusine le code pour l’améliorer, au besoin. Pour l’approche Vert-Rouge, on procède dans le sens inverse : le code est écrit avant l’écriture et l’exécution des scénarios d’essai.

L’un des avantages de l’approche Rouge-Vert est la capacité de détecter les erreurs dès le début du processus de développement, ce qui permet de réduire le nombre de bogues et d’améliorer l’efficacité des cycles de développement. L’approche met également l’accent sur le développement basé sur les tests, ce qui peut mener à un code plus fiable et précis. De plus, elle incite les développeurs à prendre en compte l’expérience de l’utilisateur dès le départ, en veillant à ce que la base de code soit conçue en ayant l’utilisateur final en tête.

Dans le cas du projet de PDA, l’approche Rouge-Vert a été appliquée lors du processus de réusinage. Ceci a mené à un processus de déploiement sans heurt, et l’application était plus fiable, plus robuste et plus facile à utiliser. En appliquant cette approche, nous avons pu relever les différents défis de programmation et d’ingénierie auxquels fait face le projet, ce qui a permis d’obtenir une application plus efficiente, plus efficace, plus stable et prête pour l’environnement de production.

Les pratiques normalisées manquent souvent dans les travaux de science des données

Si la science des données est devenue un domaine essentiel dans de nombreuses industries, elle n’est pas exempte de défis. L’un des principaux problèmes est l’absence de pratiques normalisées qui font souvent défaut dans les travaux de science des données. Bien qu’il existe de nombreuses pratiques normalisées qui peuvent améliorer la qualité, la maintenabilité et la reproductibilité du code de la science des données, de nombreux scientifiques des données les négligent au profit de solutions rapides.

La présente section aborde certaines des pratiques normalisées les plus importantes qui font souvent défaut dans les travaux de science des données. Ces pratiques comprennent :

• le contrôle de la version;
• la vérification du code (unité, intégration, système, acceptation);
• la documentation;
• l’examen du code;
• la garantie de la reproductibilité;
• le respect des règles de style (c’est-à-dire les normes PEP);
• l’utilisation des annotations de type;
• la rédaction de chaînes de documentation claires;
• la journalisation des erreurs;
• la validation de données;
• l’écriture d’un code de faible entretien;
• la mise en œuvre de processus d’intégration continue et de déploiement continu (IC/DC).

En suivant ces pratiques normalisées, les scientifiques des données peuvent améliorer la qualité et la fiabilité de leur code, réduire les erreurs et les bogues et rendre leur travail plus accessible aux autres.

Documenter le code

La documentation du code est essentielle pour rendre le code compréhensible et utilisable par d’autres développeurs. Dans le domaine de la science des données, il peut s’agir de documenter les étapes de nettoyage des données, d’ingénierie des caractéristiques, de formation des modèles et d’évaluation. Sans une documentation appropriée, il peut être difficile pour les autres de comprendre ce que fait le code, les hypothèses formulées et les compromis envisagés. L’absence de documentation appropriée peut également rendre difficile la reproduction des résultats, ce qui est un aspect fondamental de la recherche scientifique et de la création d’applications robustes et fiables.

Rédaction de chaînes de documentation claires

Les chaînes de documentation sont des chaînes qui fournissent de la documentation sur les fonctions, les classes et les modules. Elles sont généralement écrites dans un format spécial qui peut être facilement analysé par des outils comme Sphinx pour générer de la documentation. La rédaction d’une documentation claire peut aider les autres développeurs à comprendre ce que fait une fonction ou un module, les arguments qu’elle prend et ce qu’elle renvoie. Elle peut également fournir des exemples d’utilisation du code, ce qui peut permettre à d’autres développeurs d’intégrer plus facilement le code dans leurs propres projets.

def complex (real=0.0, imag=0.0):
    """Form a complex number.

    Keyword arguments:
    real -- the real part (default 0.0)
    imag -- the imaginary part (default 0.0)
    """
    if imag == 0.0 and real == 0.0:
        return compelx_zero
    ...

Exemple de chaîne de documentation multiligne

Respect des règles de style

Les règles de style relatives au code jouent un rôle crucial pour assurer la lisibilité, la maintenabilité et la cohérence d’un projet. En respectant ces règles, les développeurs peuvent améliorer la collaboration et réduire le risque d’erreurs. Une indentation cohérente, des noms de variables clairs, des commentaires concis et le respect des conventions établies sont quelques-uns des éléments clés de règles de style efficaces qui contribuent à la production d’un code de haute qualité et bien organisé. Les normes PEP (proposition d’amélioration de Python), qui fournissent des lignes directrices et de bonnes pratiques pour l’écriture du code Python, en sont un exemple. Elles garantissent que le code peut être compris par d’autres développeurs Python, ce qui est important dans les projets collaboratifs, mais aussi pour la maintenabilité générale. Certaines normes PEP traitent des conventions d’appellation (en anglais seulement), du formatage du code (en anglais seulement), et de la manière de gérer les erreurs et les exceptions (en anglais seulement).

Utilisation des annotations de type

Les annotations de type sont des annotations qui indiquent le type d’une variable ou d’un argument de fonction. Elles ne sont pas strictement nécessaires à l’exécution du code Python, mais elles peuvent améliorer la lisibilité, la maintenabilité et la fiabilité du code. Les annotations de type peuvent aider à détecter les erreurs plus tôt dans le processus de développement et à rendre le code plus facile à comprendre pour les autres développeurs. Elles offrent également une meilleure prise en charge de l’environnement de développement interactif et peuvent améliorer les performances en permettant une allocation plus efficace de la mémoire.

Contrôle de version

Le contrôle de version est le processus de gestion des modifications apportées au code et à d’autres fichiers au fil du temps. Il permet aux développeurs de suivre et d’annuler les modifications, de collaborer sur le code et de s’assurer que tout le monde travaille avec la même version de code. Dans le domaine de la science des données, le contrôle de version est particulièrement important, car les expériences peuvent générer de grandes quantités de données et de codes. En utilisant le contrôle de version, les scientifiques des données peuvent s’assurer qu’ils peuvent reproduire et comparer les résultats entre les différentes versions de leur code et de leurs données. Le contrôle de version permet également de suivre et de documenter les modifications, ce qui peut s’avérer important à des fins de conformité et de vérification.

Vérification du code

La vérification du code est la vérification formelle (et parfois automatisée) de l’exhaustivité, de la qualité et de l’exactitude du code par rapport aux résultats attendus. Il est essentiel de vérifier le code pour s’assurer que la base de code fonctionne comme prévu et que l’on peut s’y fier. Dans le domaine de la science des données, les tests peuvent inclure des essais unitaires pour les fonctions et les classes, des essais d’intégration pour les modèles et les pipelines, et des essais de validation pour les ensembles de données. En vérifiant le code, les scientifiques des données peuvent détecter les erreurs et les bogues plus tôt dans le processus de développement et s’assurer que les changements apportés au code n’introduisent pas de nouveaux problèmes. Cela permet d’économiser du temps et des ressources à long terme en réduisant la probabilité d’erreurs inattendues et en améliorant la qualité générale du code.

Examens du code

Les examens du code sont un processus au cours duquel d’autres développeurs examinent le nouveau code et les modifications apportées au code pour s’assurer qu’ils respectent les normes de qualité et de style, qu’ils sont maintenables et qu’ils répondent aux exigences du projet. Dans le domaine de la science des données, les examens du code peuvent être particulièrement importants, car les expériences peuvent générer du code et des données complexes, et parce que les scientifiques des données travaillent souvent de manière indépendante ou en petites équipes. Les examens du code permettent de détecter les erreurs, de s’assurer que le code respecte les meilleures pratiques et les exigences du projet et de promouvoir l’échange des connaissances et la collaboration entre les membres de l’équipe.

Garantie de la reproductibilité

La reproductibilité est un aspect essentiel de la recherche scientifique et de la science des données. Des résultats reproductibles sont nécessaires pour vérifier et approfondir les études antérieures et pour garantir que les résultats sont cohérents, valides et fiables. Dans le domaine de la science des données, la reproductibilité peut inclure la documentation du code et des données, l’utilisation du contrôle de version, des essais rigoureux et la fourniture d’instructions détaillées pour l’exécution des expériences. En garantissant la reproductibilité, les scientifiques des données peuvent rendre leurs résultats plus fiables et crédibles et accroître la confiance dans leurs conclusions.

Journalisation

La journalisation consiste à tenir un registre des événements qui se produisent dans un système informatique. Cela est important pour le dépannage, la collecte de renseignements, la sécurité, la fourniture de renseignements sur la vérification, entre autres raisons. Il s’agit généralement de l’écriture de messages dans un fichier journal. La journalisation est un élément essentiel du développement de logiciels robustes et fiables, y compris les applications de science des données. La journalisation des erreurs permet de cerner les problèmes liés à l’application, ce qui permet de la déboguer et de l’améliorer. En journalisant les erreurs, les développeurs peuvent savoir ce qui n’a pas fonctionné dans l’application, ce qui peut les aider à diagnostiquer le problème et à prendre des mesures correctives.

À l’aide de la journalisation, les développeurs peuvent également suivre les performances de l’application au fil du temps, ce qui leur permet de déterminer les goulots d’étranglement potentiels et les domaines à améliorer. Cela peut s’avérer particulièrement important pour les applications de science des données qui pourraient devoir traiter de grands ensembles de données ou d’algorithmes complexes.

Dans l’ensemble, la journalisation est une pratique essentielle pour développer et maintenir des applications de haute qualité de science des données.

Écriture d’un code de faible entretien

Lorsqu’il s’agit d’applications de science des données, la performance est souvent un facteur clé. Pour que l’application soit rapide et réactive, il est important d’écrire un code optimisé pour la vitesse et l’efficacité.

L’un des moyens d’y parvenir est d’écrire un code de faible entretien. Un code de faible entretien est un code qui utilise un minimum de ressources et dont le coût de calcul est faible. Cela peut contribuer à améliorer les performances de l’application, en particulier lorsqu’il s’agit de grands ensembles de données ou d’algorithmes complexes.

L’écriture d’un code de faible entretien nécessite un examen minutieux des algorithmes et des structures de données utilisés dans l’application ainsi qu’une attention particulière à l’utilisation de la mémoire et à l’efficacité du traitement. Il convient de réfléchir aux besoins, à l’architecture globale et à la conception d’un système afin d’éviter des modifications importantes de la conception en cours de route.

En outre, le code de faible entretien est facile à tenir à jour et nécessite des révisions et des mises à jour peu fréquentes. Il s’agit d’un point important, car cela réduit le coût de maintenance des systèmes et permet un développement plus axé sur les améliorations ou les nouvelles solutions.

Dans l’ensemble, l’écriture du code de faible entretien est une pratique importante pour les scientifiques des données qui souhaitent développer des applications rapides et réactives capables de gérer de grands ensembles de données et des analyses complexes tout en maintenant des coûts de maintenance faibles.

Validation des données

La validation des données consiste à vérifier que les données d’entrée répondent à certaines exigences ou normes. La validation des données est une autre pratique importante dans le domaine de la science des données, car elle permet de cerner les erreurs ou les incohérences dans les données avant qu’elles n’aient une incidence sur le processus d’analyse ou de modélisation.

La validation des données peut prendre de nombreuses formes, de la vérification du format correct des données à la vérification qu’elles soient dans les fourchettes ou les valeurs attendues. Il existe différents types de contrôles de validation des données, comme le type, le format, l’exactitude, la cohérence et l’unicité. En validant les données, les scientifiques des données peuvent s’assurer que leurs analyses sont basées sur des données exactes et fiables, ce qui peut améliorer la précision et la crédibilité de leurs résultats.

Intégration continue et déploiement continu

L’intégration continue et le déploiement continu (IC/DC) sont un ensemble de bonnes pratiques visant à automatiser le processus de création, d’essai et de déploiement de logiciels. L’IC/DC peut contribuer à améliorer la qualité et la fiabilité des applications de science des données en garantissant que les changements sont testés de manière approfondie et déployés rapidement et de manière fiable.

L’IC/DC suppose l’automatisation du processus de construction, des essais et de déploiement des logiciels, souvent à l’aide d’outils et de plateformes comme Jenkins, GitLab ou GitHub Actions. En automatisant ces processus, les développeurs peuvent s’assurer que l’application est construite et testée de manière cohérente et que les erreurs ou les problèmes qui empêchent le déploiement du code problématique sont déterminés et traités rapidement.

L’IC/DC peut également contribuer à améliorer la collaboration entre les membres de l’équipe, en garantissant que les changements sont intégrés et testés dès qu’ils sont effectués, plutôt que d’attendre un cycle de publication périodique.

Dans l’ensemble, l’IC/DC est une pratique importante pour les scientifiques des données qui souhaitent développer et déployer des applications de science des données de haute qualité de manière rapide et fiable.

Conclusion

En résumé, le code de niveau de production est essentiel pour les projets et les applications de science des données. Des pratiques de programmation appropriées et des principes de génie logiciel comme l’adhésion aux normes PEP, l’utilisation des annotations de type, la rédaction d’une documentation claire, le contrôle de version, la vérification du code, la journalisation des erreurs, la validation des données, l’écriture d’un code de faible entretien, la mise en œuvre d’une intégration continue et d’un déploiement continu (IC/DC) et la garantie de la reproductibilité sont essentiels pour créer des applications robustes, maintenables et évolutives.

Le non-respect de ces pratiques peut entraîner des difficultés comme le manque de documentation, l’absence de journalisation des erreurs, l’absence de messages d’erreur importants pour les utilisateurs, un code fortement couplé, un code trop adapté à un exemple précis, l’absence de caractéristiques souhaitées par les clients et l’absence de rétroaction en cas d’échec. Ces problèmes peuvent avoir de graves répercussions sur la préparation de la production et frustrer les utilisateurs. Si un utilisateur est frustré, sa productivité s’en ressentira, ce qui entraînera des répercussions négatives en aval sur la capacité des entreprises à remplir efficacement leur mission.

Le conseil le plus pratique pour mettre en œuvre un code de niveau de production est de travailler ensemble, d’attribuer des responsabilités et des délais clairs et de comprendre l’importance de chacun de ces concepts. Ce faisant, il devient facile de mettre en œuvre ces pratiques dans les projets et de créer des applications maintenables et évolutives.

Abonnez-vous au bulletin d'information du Réseau de la science des données pour la fonction publique fédérale pour rester au fait des dernières nouvelles de la science des données.

Par : Shannon Lo, Joanne Yoon et Kimberley Flak

Tout le monde mérite d’avoir accès à des aliments sains et abordables, peu importe où l’on vit. Cependant, de nombreux Canadiens qui vivent dans des communautés nordiques et isolées doivent faire face à des coûts accrus liés aux tarifs d’expédition et aux défis sur le plan des chaînes d’approvisionnement. En réaction aux préoccupations relatives à la sécurité alimentaire dans le Nord, le gouvernement du Canada a créé le programme de subventions Nutrition Nord Canada (NNC). Géré par Relations Couronne-Autochtones et Affaires du Nord Canada (RCAANC), ce programme aide à rendre les aliments nutritifs, comme la viande, le lait, les céréales, les fruits et les légumes, plus abordables et accessibles. Pour mieux comprendre les défis associés à la sécurité alimentaire, il faut disposer de meilleures données sur les prix.

Pour le compte de RCAANC et en collaboration avec le Centre des projets spéciaux sur les entreprises (CPSE), la Division de la science des données de Statistique Canada a réalisé un projet de validation de principe afin d’évaluer si l’approche participative constitue une solution potentielle pour combler les lacunes en matière de données. Ce projet a permis d’évaluer s’il était possible d’utiliser la reconnaissance optique de caractères (ROC) et le traitement du langage naturel (TLN) pour extraire et totaliser des renseignements sur les prix à partir d’images de reçus d’épicerie, en plus de créer une application Web pour téléverser et traiter les images de reçus. Le présent article met l’accent sur un algorithme de détermination et d’extraction de texte. Il ne présente pas le volet réservé à l’application Web.

Données

Les données d’entrée du projet comprenaient des images de reçus d’épicerie pour des achats faits dans des régions autochtones isolées, y compris des photos prises avec un appareil photo et des images numérisées. Le format et le contenu des reçus variaient selon les détaillants. À partir de ces reçus, nous avons cherché à extraire des renseignements sur les prix des produits, ainsi que des renseignements sur les reçus, comme la date et l’emplacement de l’achat, qui fournissent un contexte important en vue d’une analyse subséquente. Les données extraites ont été compilées dans une base de données afin de soutenir les fonctions de validation, d’analyse et de recherche.

Conception générale

La figure 1 illustre le flux de données, de la soumission du reçu à la numérisation, au stockage et à l’affichage. Le présent article se concentre sur le processus de numérisation.

Extraction de texte au moyen de la reconnaissance optique de caractères

Nous avons extrait du texte à partir de reçus en détectant tout d’abord les zones de texte au moyen de la méthode « Character-Region Awareness For Text detection (CRAFT) », puis par la reconnaissance de caractères au moyen de Tesseract, le moteur de ROC de Google. Nous avons choisi CRAFT au lieu d’autres modèles de détection de texte, puisqu’il détecte efficacement du texte dans des zones floues à faible résolution ou dans celles où il manque des points d’encre. Pour en savoir davantage sur CRAFT et Tesseract, voir l’article Comparaison des outils de reconnaissance optique de caractères pour les documents à forte densité de texte et les textes provenant de scènes du Réseau de la science des données.

Tesseract reconnaissait du texte à partir des zones de texte détectées. De manière générale, Tesseract cherchait les alphabets, les chiffres et la ponctuation en français et en anglais. Cependant, dans le cas des zones de texte qui commençaient à l’extrême droite (c.-à-d. celles ayant une coordonnée x à gauche au moins aux trois quarts de la coordonnée x maximale de la zone en question), Tesseract ne cherchait que les chiffres, la ponctuation et certains caractères simples servant à indiquer le type de taxe pour le produit, en supposant que la zone de texte renfermait des renseignements sur le prix. En limitant les caractères à reconnaître, nous évitions que les zéros soient reconnus comme des « O ».

Si Tesseract ne reconnaissait pas de texte dans la zone de texte ou si le niveau de confiance de la reconnaissance était inférieur à 50 %, nous avons d’abord essayé de nettoyer l’image. Les parties de texte qui présentaient une noirceur inégale ou des zones sans encre ont été comblées au moyen de l’égalisation adaptative d’histogramme à contraste limité (CLAHE en anglais). Cette méthode a permis d’améliorer le contraste global de l’image, en calculant l’histogramme de l’intensité des pixels et en répartissant ces pixels dans des plages ayant moins de pixels. La luminosité et le contraste de l’image ont été ajustés pour que le texte noir se démarque encore plus. Ces méthodes de nettoyage ont permis à Tesseract de mieux reconnaître le texte. Cependant, il n’était pas recommandé d’appliquer cette méthode de traitement préalable des images à toutes les zones de texte, puisqu’elle empêchait Tesseract de traiter certaines images prises dans des conditions différentes. Après cette méthode de traitement préalable des images, la reconnaissance de texte n’était utilisée que si la probabilité de reconnaissance de texte augmentait. Lorsque Tesseract échouait même après un traitement préalable des images, le programme utilisait le modèle « Scene Text Recognition (STR) » d’EasyOCR. Cet autre modèle de reconnaissance de texte offrait un meilleur rendement en présence d’images plus bruyantes, lorsque le texte était imprimé avec une quantité d’encre irrégulière ou que l’image était floue.

Vérification de l’orthographe

SymSpell a été entraîné au moyen de noms de produits individuels tirés de la base de données de l’Enquête sur les dépenses des ménages (EDM) de 2019. Pour améliorer la qualité de la correction, le correcteur d’orthographe sélectionnait le mot le plus courant en fonction des mots les plus semblables. Par exemple, si la ligne reconnue était « suo dried tomatoes », le correcteur d’orthographe pouvait corriger le premier mot en utilisant « sub », « sun » et « sum ». Cependant, il choisissait « sun » puisqu’il reconnaissait le digramme « sun dried », mais pas « sub dried ». D’autre part, si la ROC prévoyait que la ligne serait « sub dried tomatoes », aucun mot n’était corrigé, puisque chaque mot était une entrée valide dans la base de données. Nous avons cherché à éviter autant que possible les fausses corrections. Si un caractère n’était pas détecté en raison de la présence de lignes verticales ou du manque d’encre, le caractère manquant était aussi récupéré au moyen de la correction de l’orthographe. Par exemple, si la ligne reconnue était « sun dri d tomatoes », le correcteur d’orthographe corrigeait la ligne pour afficher « sun dried tomatoes ».

Un correcteur d’orthographe distinct corrigeait l’orthographe des noms de magasin et des noms de collectivités.

Classification de texte

Pour déterminer ce que décrivait chaque ligne de texte extrait, un classificateur d’entités au niveau du reçu et un classificateur d’entités au niveau du produit ont été créés. Les sections suivantes décrivent les entités pertinentes, les sources de données d’entraînement, les modèles envisagés et leur rendement.

Entités

Chaque rangée de texte qui était extraite a été classée dans l’un des 11 groupes présentés dans le tableau 1. Cette étape permet de caviarder des renseignements de nature délicate et d’utiliser de manière significative le reste des renseignements.

Tableau 1 : Entités extraites des reçu

Entités au niveau du reçu	Entités au niveau du produit	Autres entités
Date Nom du magasin Emplacement du magasin Sommaire de la vente	Produit Prix par quantité Subvention Réduction Dépôt	Renseignements de nature délicate (comprend l’adresse du client, le numéro de téléphone et le nom) Autre

Données d’entraînement du classificateur d’entités

Des données d’entraînement ont été recueillies à partir des reçus étiquetés, de la base de données de l’EDM et de sources publiques, comme les données accessibles dans GitHub. Voir le tableau 2 pour obtenir des renseignements détaillés sur chaque source de données d’entraînement.

Tableau 2 : Sources de données d’entraînement

Données	Enregistrements	Source	Détails supplémentaires
Détails supplémentaires	1,803	RCAANC	ROC utilisée pour extraire des renseignements à partir des images de reçus qui ont ensuite été étiquetés par les analystes.
Produits	76,392	Base de données de l’EDM	2 occurrences et plus
Nom de magasins	8,804	Base de données de l’EDM	2 occurrences et plus
Villes canadiennes	3,427	GitHub
Provinces canadiennes	26	GitHub	Communautés admissibles au programme NNC
Collectivités	131	Nutrition Nord Canada	Communautés admissibles au programme NNC
Collectivités	87,960	GitHub	Considérés comme des renseignements de nature délicate.

Sélection de modèles et réglage des hyperparamètres

Deux classificateurs à classes multiples ont été utilisés, un pour classer les entités au niveau du reçu (c.-à-d. le nom et l’emplacement des magasins), et l’autre pour classer les entités au niveau du produit (c.-à-d. la description du produit, la subvention, le prix par quantité, la réduction et le dépôt). Le tableau 3 décrit les différents modèles utilisés lors de l’expérience, afin de classer les entités au niveau du reçu et au niveau du produit. Le score F1 des macros correspondantes pour les deux différents classificateurs est également fourni.

Tableau 3 : Différents modèles mis à l’essai pour le classificateur des reçus et des produits.

Modèles mis à l’essai	Description	Score F1 selon la macro du classificateur de reçus	Score F1 selon la macro du classificateur de produits
Modèle bayésien naïf multinomial	Le classificateur bayésien naïf multinomial est idéal pour assurer une classification avec des fonctions discrètes (p. ex. nombre de mots pour la classification de texte). [1]	0.602	0.188
Machine à vecteurs de support linéaire avec entraînement au moyen de la descente par gradient stochastique	Cet estimateur met en application des modèles linéaires standardisés (p. ex. machine à vecteurs de support (SVM), régression logistique, etc.) avec entraînement au moyen de la descente par gradient stochastique : le gradient de la perte est évalué pour chaque échantillon à la fois, et le modèle est mis à jour pendant le processus, avec une courbe de force à la baisse (c.-à-d. le taux d’apprentissage). [2]	0.828	0.899
Classification à vecteurs de support linéaire	Semblable à la classification à vecteurs de support avec paramètre kernel = « linéaire », mais mis en œuvre en termes de liblinear plutôt que libsvm, ce modèle offre davantage de souplesse quand vient le temps de choisir des pénalités et des fonctions de perte. Il devrait mieux s’adapter à un grand nombre d’échantillons. Cette classe soutient les données denses et à faible densité. Le support à classes multiples est traité en fonction d’un régime axé sur le principe un contre les autres. [3]	0.834	0.900
Arbre décisionnel	Les arbres décisionnels sont une méthode d’apprentissage supervisé non paramétrique utilisée pour la classification et la régression. [4]	0.634	0.398
Forêt aléatoire	Une forêt aléatoire est un méta-estimateur qui correspond à un certain nombre de classificateurs d’arbres décisionnels pour différents sous-échantillons de l’ensemble de données, et qui utilise le calcul d’une moyenne pour améliorer l’exactitude des prédictions et contrôler le surajustement. [5]	0.269	0.206
XGBoost	XGBoost est une bibliothèque d’amplification de gradient réparti optimisée conçue pour être très efficace, souple et transférable. Elle met en œuvre des algorithmes d’apprentissage automatique dans le cadre d’amplification de gradient. [6]	0.812	0.841

Avant de choisir les modèles, on a réalisé un réglage des hyperparamètres au moyen d’une recherche par quadrillage. Nous avons ensuite utilisé la validation croisée K-Folds stratifiée pour entraîner les modèles et les mettre à l’essai, tenant compte des défis associés au déséquilibre des classes dans l’ensemble de données d’entraînement, qui comprenait principalement des renseignements de nature délicate (49 %) et le nom ou le prix des produits (44 %). La proportion restante de l’ensemble de données (7 %) comprenait des renseignements comme le nom du magasin, l’emplacement, la subvention, la réduction, la date et le prix par quantité. Après les tests et l’entraînement, les modèles affichant le meilleur rendement pour les entités au niveau du reçu et du produit ont été choisis en fonction du score F1 de la macro. Le score F1 de la macro a été utilisé comme déterminant du rendement, parce qu’il évalue l’importance de chaque classe de façon égale. Cela signifie que, même si une classe comporte très peu d’exemples parmi les données d’entraînement, la qualité des prédictions pour cette classe est tout aussi importante que celle d’une classe qui comporte de nombreux exemples. Cette situation se produit souvent dans le cadre d’un projet où l’ensemble des données d’entraînement est déséquilibré, c’est-à-dire que certaines classes ont peu d’exemples, alors que d’autres en ont plusieurs.

Une approche fondée sur les règles a été utilisée pour déterminer les dates, car les formats de dates normalisées font en sorte qu’il s’agit d’une méthode plus robuste.

Le classificateur de classification à vecteurs de support linéaire a été retenu comme le meilleur modèle pour les classificateurs de reçus et de produits en fonction de son score F1 des macros de 0,834 (reçus) et de 0,900 (produits), qui était plus élevé que dans tous les autres modèles mis à l’essai. Même s’il s’agissait du modèle affichant le meilleur rendement, il convient de souligner que l’entraînement des classificateurs de la classification à vecteurs de support prend habituellement plus de temps que les classificateurs bayésiens naïfs multinomiaux.

Coupler du texte ayant fait l’objet d’une reconnaissance optique de caractères à l’enregistrement d’un reçu

Nous avons utilisé les classificateurs entraînés d’entités au niveau du reçu et d’entités au niveau du produit sur différentes parties du reçu. Si nous supposons que le reçu était présenté comme indiqué dans la figure 2, le classificateur d’entités au niveau du reçu prédisait la classe de toutes les lignes extraites du reçu, à l’exception de la section 3 : Produits. Le classificateur d’entités au niveau du produit n’a été utilisé qu’avec la section 3 : Produits. Cette présentation fonctionnait pour tous les reçus de notre ensemble de données. Si un élément, comme le nom d’un magasin, avait été coupé de la photo, ce champ était laissé vide dans le résultat final.

Le début du reçu, où l’on trouve les sections 1) Nom et adresse du magasin et 2) Relevé de transaction, comprend des lignes de texte qui précèdent la ligne qui, selon les prédictions du classificateur de produits, affiche un produit et une valeur en dollars. Nous n’obtenions aucun nom et aucun emplacement de magasin si cette partie était vide et si la première ligne décrivait directement un produit. De l’ensemble du texte reconnu dans cette section, le texte prédit par le classificateur de reçus comme étant le nom du magasin avec la probabilité de prédiction la plus élevée a été attribué comme étant le nom du magasin. Un nom valide de communauté a été extrait des lignes qui, selon les prédictions, représentaient un emplacement. Les lignes qui, selon les prédictions du classificateur de reçus, comprenaient des renseignements de nature délicate dans cette section ont été caviardées.

La partie principale d’un reçu comprenait la section 3) Produits. Chaque ligne qui, selon le classificateur de produits, était un produit et affichait une valeur en dollars était considérée comme un nouveau produit. Toutes les lignes de texte qui suivaient ce produit et qui, selon les prédictions, étaient une subvention, une réduction, un dépôt ou le prix par quantité ont été ajoutées comme renseignements auxiliaires pour le produit. Les subventions ont ensuite été réparties entre la subvention de Nutrition Nord Canada (NNC) et la subvention pour le coût de la vie au Nunavik, en fonction de la description du texte.

La fin du reçu comprenait les sections 4) Sous-total, taxes et total et 5) Relevé de transaction. Aucune donnée ne devait être extraite de ces deux sections. Cependant, les lignes qui, selon les prédictions du classificateur de reçu, comprenaient des renseignements de nature délicate dans cette section ont été caviardées.

La date d’achat figurait au début ou à la fin du reçu. Les données ont donc été analysées en cherchant des tendances connues d’expression habituelle du format de la date dans ces sections du reçu.

Résultats

Nous avons évalué l’algorithme au moyen des photos des reçus d’épicerie de détaillants d’alimentation du Nord se trouvant dans des communautés autochtones éloignées. Des analystes du Centre des projets spéciaux sur les entreprises de Statistique Canada ont étiqueté les produits et les renseignements sur les ventes figurant dans chaque image.

Les textes extraits, notamment le nom des magasins, le nom des communautés, la description des produits et les dates, ont été évalués en fonction d’un score de similarité. La similarité entre les deux textes a été calculée en multipliant par deux le nombre total de caractères correspondants et en divisant le tout par le nombre total de caractères dans les deux descriptions. Les chiffres extraits, comme le prix du produit, la subvention, la réduction et le dépôt, ont été évalués de manière à établir une correspondance (1) ou aucune correspondance (0).

Dans le cas des champs simples, comme le nom des magasins, il était facile de comparer la valeur prédite à la valeur réelle. Néanmoins, il n’a pas été possible de réaliser une simple comparaison univoque entre les multiples éléments saisis manuellement et les multiples éléments prédits par l’algorithme de ROC. Ainsi, chaque élément saisi manuellement a été tout d’abord comparé à l’élément le plus similaire extrait par l’algorithme de ROC. Les éléments correspondants de deux sources devaient afficher un degré de similarité d’au moins 50 %. Les éléments saisis manuellement, mais non saisis par l’algorithme, étaient considérés comme des « éléments manquants ». Les éléments saisis par l’algorithme, mais non saisis manuellement, étaient considérés comme des « éléments supplémentaires ». Une fois les éléments communs appariés, la moyenne des scores de similarité pour toutes les paires a été calculée, afin d’obtenir un score de similarité global pour tous les éléments communs se trouvant sur les reçus.

L’algorithme de ROC excellait quand venait le temps de repérer des produits sur les reçus. Parmi les 1 637 produits figurant sur les reçus, 1 633 (99,76 %) ont été saisis (tableau 4). Le taux de similarité moyen de la description du produit atteignait 96,85 % (tableau 5). L’algorithme échouait lorsque le texte dans l’image était coupé, flou ou plissé, ou s’il manquait d’encre. C’est pourquoi nous avons recommandé que les extractions par ROC soient suivies par une vérification humaine réalisée au moyen de l’interface Web. Dans le cas des produits communs, les prix ont été extraits avec exactitude dans 95,47 % des cas, dans 99,14 % des cas pour les subventions de NNC, dans 99,76 % des cas pour la subvention pour le coût de la vie au Nunavik, dans 100,00 % des cas pour les réductions, dans 99,76 % des cas pour les dépôts, dans 95,71 % des cas pour le prix par quantité, et dans 95,22 % des cas pour les numéros d’article (tableau 5).

Même si la description des produits et les prix étaient toujours présents, d’autres champs, comme la subvention de NNC, n’étaient présents que lorsque c’était approprié. C’est pourquoi le tableau 5 fait aussi état des exactitudes limitées aux champs non manquants, afin d’évaluer uniquement le rendement de la ROC. Aucune entrée sur les réductions ne figurait dans ce lot de reçus. Nous avons donc utilisé un autre lot pour évaluer l’exactitude de l’extraction des réductions, qui l’ont été 98,53 % du temps. Le score de similarité du texte pour les champs observés et ayant fait l’objet d’une ROC était de 87,1 %.

Tableau 4 : Produits extraits des reçus de RCAANC

Nombre de reçus	Nombre d’éléments	Nombre d’éléments extraits	Nombre d’éléments en commun	Nombre d’éléments en commun	Pourcentage d’éléments supplémentaires
182	1,637	1,634	1,633	0.24% (4/1,637)	0.06% (1/1,630)

Tableau 5 : Exactitude de la ROC sur les renseignements au niveau du produit

	Description du produit (Score moyen de similarité du texte)	Prix (% d’exactitude)	Subvention de NNC (% d’exactitude)	Subvention pour le coût de la vie au Nunavik (% d’exactitude)	Réduction (% d’exactitude)	Dépôt (% d’exactitude)	Numéro d’article (% d’exactitude)	Numéro d’article (% d’exactitude)
Exactitude des éléments en commun	96.85%	95.47% (1,559/1,633)	99.14% (1,619/1,633)	99.76% (1,629/1,633)	100.0% (1,633/1633)	99.76% (1,629/1,633)	95.71% (1,563/1,633)	95.22% (1,555/1,633)
Exactitude des éléments en présence de champs	96.85%	95.47% (1,559/1,633)	99.08% (647/653)	100.0% (282/282)	Not available. No actual occurrence	97.56% (160/164)	72.97% (81/111)	95.52% (1,555/1,628)

Les renseignements sur les reçus ont été extraits de façon efficace sans qu’aucune communauté, aucun nom de magasin ou aucune date n’ait été complètement omis ou faussement assigné. Le score moyen de similarité du texte était constamment élevé : 99,12 % pour la communauté, 98,23 % pour les noms de magasins, et 99,89 % pour les dates. L’utilisation de l’algorithme de ROC et du classificateur d’entités de reçu pour traiter les reçus semble prometteuse.

En outre, 88,00 % des renseignements de nature délicate ont été caviardés correctement. Parmi les renseignements qui n’ont pas été caviardés, il s’agissait en grande partie des numéros d’identification des caissiers. Ces données n’ont pas été caviardées, car le classificateur d’entités n’avait jamais vu ce type de renseignement de nature délicate. Un nouvel entraînement du classificateur d’entités au moyen d’exemples de numéros d’identification de caissiers permettra d’améliorer les résultats, comme cela se produit dans le cas du nom des caissiers, alors que le classificateur reconnaît que les noms des caissiers sont des renseignements de nature délicate, en raison d’exemples comme « <Nom du caissier> était votre caissier aujourd’hui » dans ses données d’entraînement.

Tableau 6 : Exactitude de la ROC sur les renseignements au niveau du reçu

	Nombre de reçus	Nom du magasin (Score moyen de similarité du texte)	Nom du magasin (Score moyen de similarité du texte)	Nom du magasin (Score moyen de similarité du texte)	Renseignements de nature délicate (% de rappel)
Évaluation	182	98.23%	99.12%	99.89%	88.80
Évaluation en présence de champs	164	99.02%	99.88%	98.03%	Not applicable

Conclusion

Ce projet a montré qu’une classification d’entités et un algorithme de ROC peuvent saisir, avec exactitude, différentes composantes des reçus d’épicerie des détaillants du Nord. L’automatisation de ce processus facilite la collecte de données sur le coût de la vie dans le Nord. Si cette solution est mise de l’avant, l’automatisation devrait être suivie par un processus de validation avec intervention humaine, par l’intermédiaire d’une interface Web, afin de s’assurer que les reçus soient numérisés correctement et que les corrections soient utilisées, de manière itérative, pour réaliser un nouvel entraînement. Cette fonction de validation a été mise en œuvre, mais n’est pas abordée dans le présent article.

Les données anonymisées agrégées qui sont recueillies dans le cadre d’une approche participative pourraient fournir de meilleures explications associées au coût élevé des aliments dans les communautés autochtones isolées, en plus d’accroître la transparence et la reddition de comptes des bénéficiaires de la subvention Nutrition Nord Canada auprès des résidents de ces communautés. Si vous souhaitez en apprendre davantage sur le volet de l’application Web, veuillez envoyer un courriel, à datascience@statcan.gc.ca.

Abonnez-vous au bulletin d'information du Réseau de la science des données pour la fonction publique fédérale pour rester au fait des dernières nouvelles de la science des données.

Références (en anglais seulement)

1. sklearn.naive_bayes.MultinomialNB — scikit-learn 1.2.0 documentation
2. sklearn.linear_model.SGDClassifier — scikit-learn 1.2.0 documentation
3. sklearn.svm.LinearSVC — scikit-learn 1.2.2 documentation
4. 1.10. Decision Trees — scikit-learn 1.2.0 documentation
5. sklearn.ensemble.RandomForestClassifier — scikit-learn 1.2.0 documentation
6. XGBoost Documentation — xgboost 1.7.2 documentation

Par : Keven Bosa, Statistique Canada

De plus en plus de données sont générées au quotidien. On n'a qu'à penser aux données de téléphonie cellulaire, d'images satellites, de navigation sur internet ou de lecteur optique. La profusion de données fait grandir l'appétit de la population pour des statistiques nouvelles, plus détaillées et plus actuelles. Comme plusieurs autres organismes nationaux de statistique, Statistique Canada a adhéré à cette nouvelle réalité et utilise de plus en plus de sources de données alternatives afin d'améliorer et moderniser ses différents programmes statistiques. Étant donné leur volume et leur vélocité, des méthodes d'apprentissage automatique sont souvent nécessaires pour utiliser ces nouvelles sources de données.

Statistique Canada a mené plusieurs projets faisant appel à des méthodes d'apprentissage automatique au cours des trois dernières années. Par exemple, les scientifiques de données se sont servis du traitement de langage naturel pour attribuer une classe à des commentaires provenant de répondants au recensement ainsi qu'à d'autres enquêtes. Des méthodes d'apprentissage non supervisé ont été utilisées pour partitionner la base canadienne de données des coroners et des médecins légistes en groupes homogènes afin d'améliorer la compréhension de certains phénomènes. Un algorithme d'apprentissage supervisé a été développé pour prédire le rendement des cultures. Des projets utilisant des réseaux neuronaux sur des images satellites sont actuellement en cours pour optimiser le programme de l'agriculture. Dans un cas, l'objectif est de détecter la présence de serres alors que dans un autre cas, le but est d'identifier les différents types de grandes cultures. Un algorithme a aussi été élaboré pour extraire de l'information financière provenant de documents PDF. Les exemples précédents donnent une idée de la diversité des problèmes pour lesquels l'apprentissage automatique est utilisé.

L'utilisation de l'apprentissage automatique comprend son lot d'avantages : traitement des données volumineuses et non structurées, automatisation des processus en place, amélioration de la couverture et de la précision et bien d'autres. Toutefois, elle soulève aussi plusieurs questions. Par exemple :

• Est-ce que le processus protège l'intégrité et la confidentialité des données?
• Est-ce que la qualité des données d'entraînement est adéquate pour le but poursuivi?
• Une fois l'algorithme mis en place, qui est responsable des résultats et des effets qui en découlent?

Suite à ces questions et à l'augmentation de l'utilisation de méthodes d'apprentissage automatique à Statistique Canada, la Direction des méthodes statistiques modernes et de la science des données a reconnu le besoin d'un cadre pour guider l'élaboration des processus d'apprentissage automatique et d'en faire des processus responsables.

Le Cadre pour l'utilisation des processus d'apprentissage automatique de façon responsable à Statistique Canada sera présenté dans cet article, puis sera suivi d'une brève explication du processus de revue mis en place pour l'appliquer. Finalement, cet article se conclura en proposant quelques réflexions et en mentionnant quelques travaux futurs.

Présentation du Cadre

Avant de présenter le cadre de travail dont s'est doté Statistique Canada, nous ferons un bref survol de la Directive sur la prise de décisions automatisée établie par le Secrétariat du conseil du trésor. Celle-ci a d'ailleurs fait l'objet d'un article présenté dans l'édition du mois de juin du bulletin. Il y est mentionné que : « La présente Directive a pour objet de veiller à ce que les systèmes décisionnels automatisés soient déployés d'une manière qui permet de réduire les risques pour les Canadiens et les institutions fédérales, et qui donne lieu à une prise de décisions plus efficace, exacte et conforme, qui peut être interprétée en vertu du droit canadien. » Il est aussi mentionné que la Directive « … s'applique à tout système, outil ou modèle statistique utilisé pour recommander ou prendre une décision administrative au sujet d'un client.». À Statistique Canada, tous les projets utilisant l'apprentissage automatique ou, de façon plus générale la modélisation, font partie d'un programme statistique dont le but n'est pas de prendre des décisions administratives sur un client, du moins, pas jusqu'à présent. Statistique Canada n'a donc pas encore eu à se conformer à cette Directive et à évaluer l'incidence de ces décisions à l'aide de l'Outil d'évaluation de l'incidence algorithmique. Toutefois, comme mentionné à la fin de la section précédente, Statistique Canada a été proactif en adoptant ce Cadre afin de s'assurer d'une utilisation responsable de l'apprentissage automatique au sein de l'agence.

La figure 1 donne un bon aperçu du Cadre pour l’utilisation des processus d’apprentissage automatique de façon responsable à Statistique Canada.

Le cadre comprend des lignes directrices pour l'usage responsable de l'apprentissage automatique organisées en quatre thèmes : respect des personnes; respect des données; application rigoureuse; méthodes éprouvées. Les quatre thèmes mis en commun assurent l'utilisation éthique des algorithmes et des résultats de l'apprentissage automatique. Ces lignes directrices s'appliquent à tous les programmes et projets statistiques menés par Statistique Canada qui utilisent des algorithmes d'apprentissage automatique, particulièrement ceux mis en production. Cela comprend les algorithmes d'apprentissage supervisé et non supervisé.

Le thème respect des personnes est décrit à l'aide de quatre attributs.

1. Le concept de valeur pour les Canadiens dans un contexte d'apprentissage automatique implique que son utilisation doit avoir une valeur ajoutée, que ce soit dans les produits eux-mêmes ou par une plus grande efficacité dans le processus de production.
2. La prévention des préjudices nécessite d'être au courant des dangers potentiels et d'avoir un dialogue constructif avec les intervenants et les porte-paroles du milieu avant la mise en œuvre d'un projet d'apprentissage automatique.
3. L'équité implique que le principe de la proportionnalité entre les moyens et les fins soit respecté, et qu'un équilibre soit maintenu entre des intérêts et des objectifs différents. L'équité veille à ce que les personnes et les groupes ne soient pas victimes de préjugés injustes, de discrimination ou de stigmatisation.
4. L'imputabilité est l'obligation juridique et éthique d'une personne ou d'une organisation d'être responsable de son travail et de communiquer les résultats du travail de façon transparente. Les algorithmes ne sont pas responsables; quelqu'un est responsable des algorithmes.

Statistique Canada prend les données au sérieux. Le thème respect des données a trois attributs : la protection de la vie privée des personnes auxquelles les données appartiennent; la sécurité des renseignements tout au long du cycle de vie des données; et la confidentialité de renseignements identifiables.

1. La vie privée est le droit de se retirer et de ne pas être sujet à une quelconque forme de surveillance ou d'intrusion. Lors de l'acquisition de renseignements de nature délicate, les gouvernements ont des obligations relativement à la collecte, à l'utilisation, à la divulgation et à la conservation des renseignements personnels. Le terme vie privée réfère généralement à des renseignements concernant des particuliers (définition tirée de Politique sur la protection des renseignements personnels et la confidentialité).
2. La sécurité représente les dispositions fondées sur l'évaluation de la menace et des risques qu'utilisent les organisations pour empêcher l'obtention ou la divulgation inadéquate de renseignements confidentiels. Les mesures de sécurité protègent aussi l'intégrité, la disponibilité et la valeur des fonds de renseignements. Cela englobe les protections matérielles, comme l'accès restreint aux zones où les renseignements sont entreposés et utilisés ou les autorisations de sécurité des employés, ainsi que les protections technologiques utilisées pour empêcher l'accès électronique non autorisé (définition tirée de la Politique sur la protection des renseignements personnels et la confidentialité).
3. La confidentialité fait référence à la protection contre la divulgation de renseignements personnels identifiables concernant une personne, une entreprise ou une organisation. La confidentialité suppose une relation de « confiance » entre le fournisseur de renseignements et l'organisation qui les recueille; cette relation s'appuie sur l'assurance que ces renseignements ne seront pas divulgués sans l'autorisation de la personne ou sans l'autorité législative appropriée (définition tirée de la Politique sur la protection des renseignements personnels et la confidentialité).

Une application rigoureuse signifie de mettre en place, de maintenir et de documenter les processus d'apprentissage automatique de façon à ce que les résultats soient toujours fiables et que l'ensemble du processus puisse être compris et recréé. Ce thème a deux attributs : la transparence et la reproductibilité du processus et des résultats.

1. La transparence fait référence au fait d'avoir une justification claire de la raison pour laquelle cet algorithme et les données d'apprentissage sont les plus appropriés pour l'étude en cours. Pour être transparents, les développeurs devraient produire une documentation complète, y compris rendre accessible le code informatique à d'autres personnes, et ce, sans compromettre la confidentialité ou la protection des renseignements personnels.
2. La reproductibilité du processus signifie qu'il y a suffisamment de documentation et que le code informatique a été suffisamment partagé pour faire en sorte que le processus soit reproduit, à partir de rien. La reproductibilité des résultats signifie que les mêmes résultats peuvent être reproduits de façon fiable lorsque toutes les conditions sont contrôlées. Il n'y a pas d'étapes qui modifient les résultats à la suite d'une intervention ponctuelle ou humaine.

Les méthodes éprouvées sont celles qui peuvent être invoquées de manière efficace et efficiente afin de produire les résultats espérés. Statistique Canada suit habituellement des protocoles reconnus qui comportent une consultation avec des pairs et des experts, de la documentation et des tests lorsque nous élaborons des méthodes éprouvées. Ce thème a quatre attributs : la qualité des données d'apprentissage; l'inférence valide; la modélisation rigoureuse; l'explicabilité.

1. Dans un contexte d'apprentissage automatique, la qualité des données d'apprentissage est mesurée par la cohérence et l'exactitude des données étiquetées. La couverture, ce qui signifie que les étiquettes et les descriptions couvrent tous les cas auxquels l'algorithme peut faire face dans la production, est également importante pour réduire le risque de partialité ou de discrimination (équité). La couverture est également importante pour assurer la représentativité des variables, ce qui est important lorsqu'on veut obtenir des mesures de rendement réalistes.
2. Une inférence valide désigne la capacité d'obtenir, à partir d'un échantillon, des conclusions plausibles et d'une précision connue de la population cible. Dans un contexte d'apprentissage automatique, une conclusion valable signifie que les prédictions à partir de données tests (jamais utilisées pour la modélisation) doivent être, dans une grande proportion, raisonnablement près de leurs vraies valeurs ou, dans le cas de données catégoriques, les prédictions sont exactes dans une grande proportion.
3. Une modélisation rigoureuse en apprentissage automatique consiste à s'assurer que les algorithmes sont vérifiés et validés. Cela permettra aux utilisateurs et aux décideurs de faire confiance à l'algorithme à juste titre du point de vue de l'adaptation des données à leur utilisation, de la fiabilité et de la robustesse.
4. Un modèle qui est explicable est un modèle qui est suffisamment documenté. Les documents doivent expliquer clairement de quelle façon les résultats devraient être utilisés et permettre de déterminer quelles conclusions on peut tirer ou encore ce qui devrait être exploré plus en profondeur. En d'autres mots, un modèle explicable n'est pas une boîte noire.

Processus de revue

Le processus de revue constitue la mise en œuvre du Cadre. L'accent est mis sur les projets ayant des visées pour l'utilisation de méthodes d'apprentissage automatique dans une ou plusieurs étapes menant à la production de statistiques officielles. Le processus comprend trois étapes : l'auto-évaluation à l'aide de la liste de contrôle; l'évaluation par des pairs; une présentation du projet au comité d'examen scientifique de la Direction des méthodes statistiques modernes et de la science des données.

Dans un premier temps, l'équipe ayant développé le projet à l'aide de méthodes d'apprentissage automatique devra faire une auto-évaluation concernant l'utilisation de ces techniques. Pour se faire, l'équipe devra prendre connaissance du Cadre et répondre aux questions présentes dans la liste de contrôle. La liste de contrôle prend la forme d'un questionnaire où, de façon générale, chaque ligne directrice du Cadre est reformulée sous forme d'une ou plusieurs questions. Par la suite, ce questionnaire et la documentation du projet et des méthodes utilisées sont envoyés à l'équipe de revue.

L'évaluation par les pairs peut maintenant débuter. Des réviseurs provenant de deux équipes différentes seront impliqués. Les questions et la documentation concernant les deux premiers thèmes du Cadre, respect des personnes et respect des données, seront évaluées par l'équipe du Secrétariat de l'éthique des données alors que la partie concernant les deux derniers thèmes, application rigoureuse et méthodes éprouvées, sera évaluée par une équipe de la section des méthodes et de la qualité en science des données. À la fin de cette évaluation, un rapport contenant des recommandations sera envoyé au gestionnaire du projet.

La dernière étape du processus de revue est la présentation du projet au comité d'examen scientifique de la Direction des méthodes statistiques modernes et de la science des données. Cette présentation expose la méthodologie utilisée lors du processus d'apprentissage automatique devant un comité d'experts. Le rôle de ce comité est de remettre en question la méthodologie notamment en identifiant certaines lacunes ou problèmes potentiels et en proposant des améliorations et des corrections. Ultimement, ce comité recommandera ou non la mise en œuvre de la méthodologie proposée dans le contexte de production de statistiques officielles.

Et après?

Est-ce la fin de l'histoire? Non, en fait c'est plutôt le début. De nouvelles sources de données et méthodes d'apprentissage automatique émergent pratiquement chaque jour. Afin de demeurer pertinent, le Cadre présenté dans cet article devra être fréquemment adapté et révisé pour tenir compte des nouveaux enjeux d'éthique et de qualité. Statistique Canada continue à appliquer ce Cadre aux processus qui utilisent l'apprentissage automatique et est à l'affût d'applications où la Directive sur la prise de décisions automatisée pourrait s'appliquer. L'agence va constituer un registre de toutes les applications qui ont passé ce processus de revue pour pouvoir y référer facilement. Et vous, faites-vous face à des questions concernant l'utilisation responsable de certaines méthodes d'apprentissage automatique? Avez-vous déjà appliqué la Directive du Secrétariat du Conseil du trésor et avez-vous déjà dû obtenir une évaluation indépendante d'une de vos applications? À Statistique Canada nous avons déjà fait ce genre de revue pour un autre ministère à l'aide du Cadre discuté dans cet article et sommes disponibles pour faire d'autres revues si le besoin se présente. Veuillez contacter statcan.dscd-ml-review-dscd-revue-aa.statcan@statcan.gc.ca.

Par : Andres Solis Montero, Statistique Canada

La première étape du cycle de vie du développement logiciel (CVDL) d'un projet d'apprentissage automatique consiste à définir l'énoncé du problème et les objectifs. Ensuite, il s'agit de recueillir, d'analyser et de traiter les données. Le processus se poursuit avec de multiples itérations, parfois perpétuelles, de modélisation, d'entraînement, d'ajustement d'hyperparamètres, de tests et d'évaluation. Ces étapes sont essentielles à l'élaboration d'un modèle efficace et accaparent la majeure partie du temps et de l'attention consacrés au développement. Mais que se passe-t-il ensuite? Empaquetage et déploiement de logiciel? La plupart du temps, l'objectif final est de livrer un produit aux clients, de mettre le code à la disposition d'autres équipes ou d'utilisateurs aux fins de collaboration, ou simplement de communiquer le travail effectué et les résultats avec le reste du monde.

Le déploiement ne devrait pas être simplement la dernière étape du cycle de développement. L'intégration progressive de bonnes pratiques de génie logiciel et d'outils libres peut améliorer les compétences en développement ainsi que la capacité d'une organisation à fournir des applications et des services plus rapidement. Cette approche permet de créer un produit de A à Z qui peut être facilement partagé et déployé sans répercussions importantes sur le temps de modélisation et de développement.

Un modèle de projet conforme aux pratiques et aux outils mentionnés dans le présent article est accessible au public. Ce modèle peut constituer votre première étape dans l'élaboration de projets d'apprentissage automatique. N'hésitez pas à fourcher le projet et à étendre ses fonctionnalités. Une autre caractéristique intéressante de cette structure de projet est la séparation de la logique applicative pour le déploiement, ce qui lui permet de se conformer aux normes du gouvernement du Canada sur les API pour la prestation de services Web sécurisés par l'entremise du protocole HTTPS sans avoir à transformer votre code. Dans cet article, on a établi que Python est le langage de programmation utilisé. Cependant, les méthodologies et les solutions qui y sont présentées pourraient également être mises en œuvre en utilisant un autre langage de programmation.

Contrôle des versions

La première pratique pertinente à employer au moment du déploiement d'un projet d'apprentissage automatique en tant que service est le contrôle des versions. Le recours au contrôle des versions pour les projets d'analyse a été abordé dans un article précédent qui soulignait également son importance et sa valeur. Le présent article porte sur une structure de projet à utiliser dans votre système de contrôle des versions.

Cette structure reflète le code prêt à la production dans la branche principale. D'autres branches reproduiront la même structure de dossiers, mais serviront à différentes étapes de développement, comme l'élaboration de versions différentes, la mise à l'essai, les nouvelles fonctions et l’expérimentation. L'objectif de la branche principale est qu'elle soit toujours prête à l'emploi, ce qui signifie que vous pouvez la déployer à tout moment. De plus, vous pouvez avoir plusieurs branches de la branche principale qui traitent des problèmes de production ou de développement.

Les flux de travail et l'utilisation de Git sont un vaste sujet et hors de la portée du présent article. Consultez la documentation publique pour obtenir plus de détails sur les directives d'utilisation de Git.

Documentation

La deuxième pratique dont il faut tenir compte est la documentation. La documentation du code est une étape importante pour vous assurer que votre projet d'apprentissage automatique est compréhensible et prêt à être déployé. La rédaction de la documentation peut être intimidante si vous essayez de la rassembler à la fin d'un projet. Grâce à quelques pratiques et outils raisonnables, le travail peut être plus facile à gérer.

Un projet bien documenté devrait cibler de multiples utilisateurs, depuis les développeurs et les spécialistes de la maintenance jusqu'aux utilisateurs, aux clients et aux intervenants. Le principal intérêt des développeurs et des spécialistes de la maintenance est de comprendre les détails de mise en œuvre et les interfaces de programmation d'applications (API) exposées. Les utilisateurs, les clients et les intervenants veulent savoir comment utiliser la solution, les sources de données, les pipelines d'extraction, de transformation et de chargement (ETL) et comprendre les expériences et les résultats.

Une bonne documentation de projet est élaborée au fur et à mesure que le projet avance, dès le début, et pas seulement lorsque le projet est terminé. Les outils de source libre tels que Sphinx peuvent générer automatiquement de la documentation à partir des commentaires Docstring. Documenter le code tout au long du cycle de développement de votre projet est un exercice qui devrait être encouragé et que votre équipe devrait suivre. Suivre le format des normes Docstring lors de la rédaction du code peut aider à créer une documentation exhaustive du code. Les chaînes de documentation (docstrings) sont un excellent moyen de générer de la documentation API lorsque vous rédigez du code en présentant vos modèles, paramètres, fonctions et modules. L'exemple de chaîne de documentation suivant montre la fonction mlapi.main.train.

async def train(gradient_boosting: bool = False) -> bool:
    """ 
    FastAPI POST route '/train' endpoint to train our model     

    Args:
         gradient_boosting: bool            
                A boolean flag to switch between a DTreeClassifier or GradientBoostClassifier

    Returns:
           bool:
  A boolean value identifying if training was successful.  
    """
    data = clf.dataset()
    return clf.train(data['X'], data['y'], gradient_boosting)

L'intégration de Sphinx avec des déclencheurs dans le système de contrôle des versions permet d'analyser la structure de notre projet à chaque validation, de rechercher les chaînes de documentation existantes et de générer automatiquement notre documentation. Dans notre exemple de projet, le fichier de configuration .gitlab.yaml intégrera nos validations à la branche principale avec Sphinx pour générer automatiquement la documentation API de notre code, comme indiqué ci-dessous.

Par ailleurs, les utilisateurs, les clients et les intervenants peuvent profiter de nos descriptions de projet de haut niveau, comme les détails de la modélisation, les objectifs, les sources de données d'entrée, les pipelines ETL, les expériences et les résultats. Nous complétons la documentation du code en créant manuellement des fichiers dans le dossier docs/markdown/. Sphinx prend en charge les formats ReStructuredText (.rst) et Markdown (.md), ce qui simplifie la génération de documents HTML et PDF. Notre projet tire parti des formats de fichier .rst et .md, stockés dans le dossier docs/ et précisés dans le fichier index.rst.

L'envoi du code à notre branche principale déclenchera la génération automatique de documentation en inspectant toutes les chaînes de documentation du code dans le dossier source. Au cours du même processus, les Markdown indiqués dans l'index sont liés dans le site Web de la documentation finale. Il est également important de préciser un fichier README.md de haut niveau contenant un guide d'utilisation rapide avec des liens pertinents et un fichier LICENCE divulguant nos conditions d'utilisation pour les clients et les utilisateurs.

Interfaces API REST

La troisième pratique dont il faut tenir compte pour le déploiement des projets d'apprentissage automatique est l'utilisation des interfaces API REST. Le gouvernement du Canada a mis l'accent sur l'utilisation des API comme moyen de déploiement des interfaces API en tant que service Web client-serveur, suivant un style architectural de transfert d'état représentationnel (REST).

FastAPI est un cadre Web moderne et performant pour la création d'API REST. Cet outil de source libre de plus en plus populaire tire parti des annotations de type Python pour convertir automatiquement les objets Python en représentations JSON et vice versa.

Parlons un peu de la mise en œuvre du modèle dans notre projet avant de convertir son interface API en API Web REST. Sans perdre de vue la généralité, nous avons choisi un modèle de classification simple et supervisé. Le présent article ne porte pas sur l'entraînement des modèles, alors nous le garderons simple à des fins d'explication.

Dans le projet couplé, nous avons sélectionné l'ensemble de données Iris pour entraîner un modèle de classification. L'ensemble de données contient quatre caractéristiques (c.-à-d. longueur et largeur du sépale, et longueur et largeur du pétale). Ces caractéristiques sont utilisées pour classer chaque observation dans trois classes : Setosa, Versicolour et Virginica.

Nous entraînons notre modèle avec deux classificateurs simples, DecisionTreeClassifier et GradientBoosterClassifier, et nous les utilisons pour faire des prévisions. La description et la mise en œuvre de notre modèle IrisClassifier se trouvent sous src/mlapi/ml/classifier.py et contiennent cinq appels de méthode (c.-à-d. entraînement, téléchargement, chargement, enregistrement et prévision).

Voyons maintenant comment nous pouvons partager notre modèle en tant que service Web. Tout d'abord, nous créons une instance d'application FastAPI et un classificateur dans une application FastAPI. Le point d'entrée se trouve dans le fichier src/mlapi/main.py

app = FastAPI(title="MLAPI Template", description="API for ml model", version="1.0")
"""FastAPI app instance"""

clf = IrisClassifier.load()
"""Classifier instance"""

La méthode IrisClassifier.load() renvoie un classificateur déjà entraîné.

Ensuite, nous commençons par préciser nos chemins HTTP publics pour connecter notre service Web à l'interface API du classificateur.

@app.post("/train")
async def train(gradient_boosting: bool = False):
    """ Docstring """
    data = clf.dataset()
    clf.train(data['X'], data['y'], gradient_boosting)
    return True

Le chemin POST HTTP @app.post('/train') accepte un indicateur booléen pour basculer entre nos deux options de classificateurs mentionnées précédemment. Pour chaque demande de chemin à /train, notre service Web entraînera de nouveau le classificateur à l'aide de l'ensemble de données Iris et de l'indicateur gradient_boostring et mettra à jour l'instance du classificateur (c.-à-d. clf).

Ensuite, nous définissons le chemin qui prendra en charge nos demandes de prévisions; il s'agira d'une méthode « post » à /predict.

@app.post("/predict",response_model=IrisPredictionResponse)
async def predict(iris: IrisPredictionInput) :
    """ Docstring """
    return clf.predict(iris.data)

Cette méthode prend une IrisPredictionInput afin de s'assurer que le format des données de la demande est correct et retourne la classe IrisPredictionResponse avec les probabilités pour chaque catégorie. Une IrisPredictionInput contient un membre de données avec une liste de caractéristiques d'observation de taille quatre, comme indiqué dans notre ensemble de données Iris. FastAPI inspecte les annotations de type Python pour convertir la charge utile « post » JSON aux objets Python valides que nous avons déclarés dans le même fichier main.py

class IrisPredictionInput(BaseModel):
    """ Docstring """
    data: List[conlist(float, min_items=4, max_items=4)]

class IrisPredictionResponse(BaseModel):
    """ Docstring """
    prediction: List[int]
    probability: List[Any]

Enfin, lançons notre service Web

src/mlapi$ uvicorn main:app --reload --host 0.0.0.0 --port 8888

Ouvrez https://127.0.0.1:8888/docs dans votre navigateur Web. Comme nous avons suivi les pratiques exemplaires avec diligence, FastAPI a été en mesure de créer automatiquement une bonne application Web Swagger pour documenter et tester notre interface API. Bien que cela démontre à quel point il est facile d'utiliser ces pratiques de développement, il ne s'agit que d'un modeste exemple d'application. Enfin, votre certificat d'organisation et votre clé privée peuvent être transmis à uvicorn pendant le déploiement, fournissant une couche de communication HTTPS sécurisée pour votre interface API. Il n'est pas nécessaire de changer votre code ni de le modifier pour le sécuriser, car uvicorn intégrera le protocole de sécurité de la couche transport (TLS) simplement en lui disant où trouver le certificat. Notre structure de projet permet de séparer la logique applicative entre votre code et le déploiement facile du protocole TLS.

src/mlapi$ uvicorn main:app --host 0.0.0.0 --port 8888 –ssl-keyfile=./key.pem --ssl-certificate=./cert.pem

Si votre organisation dispose d'une solide infrastructure TLS grâce à d'autres systèmes, ceux-ci peuvent être associés au conteneur pour faciliter encore plus le processus. Il existe de nombreuses façons de mettre en œuvre le protocole TLS.

Mise en conteneur

La quatrième pratique à mettre en œuvre pendant le déploiement de votre projet d'apprentissage automatique est la mise en conteneur. La mise en conteneur est une forme de virtualisation du système d'exploitation où les applications s'exécutent dans des espaces utilisateurs isolés. Un conteneur est essentiellement un environnement informatique entièrement intégré qui contient tout ce dont une application a besoin d'exécuter (p. ex. le code et toutes ses dépendances). Le conteneur est extrait du système d'exploitation hôte, ce qui lui permet d'exécuter le même code dans n'importe quelle infrastructure sans avoir besoin que le code soit retravaillé (c.-à-d. tout système d'exploitation, machine virtuelle ou nuage).

L'avantage du codage de nos projets d'apprentissage automatique à l'aide d'un conteneur est de contrôler toutes nos dépendances logicielles et notre environnement. Par conséquent, nous nous assurons qu'il peut être partagé et exécuté comme prévu au départ. Qu'est-ce que cela signifie? Nous créons un fichier de description d'image Docker définissant nos dépendances et le processus en cours d'exécution. Cela n'a pas d'incidence sur notre modèle ni sur les mises en œuvre, mis à part la structure de dossiers proposée; cela reflète toutes les dépendances de notre code.

Il y a trois exigences de base dans notre modèle pour créer la description d'image Docker personnalisée (c.-à-d. Dockerfile) utilisée pour exécuter notre modèle en tant que service. Premièrement, les images Docker permettent l'héritage, ce qui signifie que nous pouvons tirer parti des images qui utilisent la plupart des mêmes bibliothèques et dépendances que notre projet. Par exemple, nous pourrions choisir d'étendre notre Dockerfile à partir d'une image à l'aide de scikit-learn, pytorch, tensorflow, Keras ou Caffe. Deuxièmement, nous ferons le suivi des dépendances des progiciels Python que nous utilisons dans notre projet à l'intérieur du fichier requirements.txt. Enfin, nous précisons le point d'entrée des commandes de notre conteneur pour exécuter notre application principale.

Dockerfile

FROM tiangolo/uvicorn-gunicorn-fastapi:python3.7

WORKDIR /tmp
COPY requirements.txt requirements.txt
RUN pip install -r requirements.txt

COPY . /app
WORKDIR /app
CMD ["uvicorn", "main:app", "--reload", "--host", "0.0.0.0", "--port", "8888"]

Le fichier requirements.txt contient un seul nom de progiciel Python par ligne, précisant une dépendance Python nécessaire à notre projet.

requirements.txt

fastapi
uvicorn
pydantic
starlette
python-multipart
requests
scikit-learn
joblib

Nous pouvons maintenant transformer le fichier de définition en image Docker et exécuter le conteneur pointant vers notre service FastAPI

src/mlapi$ docker build -t mlapi .
src/mlapi$ docker run -d -p 8888:8888 --name ml-mlapi mlapi

Modularisation

La cinquième et dernière pratique soulignée dans le présent article est la modularisation. La modularisation est une technique utilisée pour diviser un système logiciel en plusieurs modules distincts et indépendants capables d'effectuer des tâches de façon indépendante. Ces modules sont considérés comme des concepts de base pour l'application.

Si nous voulons élaborer un code lisible et facile à maintenir, nous devons utiliser une conception modulaire. Il est essentiel de séparer notre code en blocs fonctionnels unitaires réutilisables. La division de notre code en différents blocs fonctionnels unitaires nous permet d'exécuter l'ensemble de la solution en les regroupant. Bien que ces derniers soient tous dans un scénario de cas par cas et dépendent du projet, les projets d'apprentissage automatique ont des blocs très déterminants comme les pipelines ETL de données, l'analyse, l'entraînement, les tests, les résultats et la production de rapports. La séparation de ces logiques dans différents modules de code rend notre code Python lisible et facile à maintenir tout en maintenant les coûts de production bas et en accélérant notre cycle de développement. Un code qui n'est pas modulaire prend plus de temps à passer à la production, et il est sujet à des erreurs et à des configurations défaillantes. Il devient difficile d'examiner les codes plusieurs fois avant le déploiement.

Les carnets Jupyter constituent l'un des outils les plus couramment utilisés pour le prototypage d'applications d'apprentissage automatique. Ils nous permettent d'exécuter des cellules de code et de les documenter au même endroit. Malheureusement, ils ne sont pas adaptés au déploiement d'un projet; nous devons traduire leur code en modules Python. Nous pourrions considérer les cellules des carnets comme des composantes de notre prototype. Une fois testées, une ou plusieurs cellules de code pourraient être intégrées à une fonction ou à un module Python sous un dossier src/mlapi/ml. Ensuite, nous pouvons les importer de nos cahiers et poursuivre le prototypage.

Pendant le prototypage de nos modèles, les carnets Jupyter doivent être sauvegardés dans le dossier src/mlapi/, à côté du point d'entrée main.py de l'API REST. Cela garantit que notre code de prototypage et de production maintient les mêmes importations de chemin de module absolu. De plus, de la même façon que nous présentons notre code, la documentation du projet pourrait suivre le même flux de travail. Les cellules Markdown de Jupyter contenant des renseignements importants sur l'application doivent être déplacées vers des documents.md docs/markdown/<document>, élargissant la documentation de notre projet. N'oubliez pas d'ajouter la référence à notre fichier Sphinx docs/index.rst. Ces pages de documentation peuvent encore être référencées à partir de notre carnet de prototypage en établissant un lien vers leur emplacement de publication final.

Une autre bonne pratique de modularisation consiste à limiter la quantité de valeurs de variables figées dans le code de notre application, à créer des fichiers de configuration qui font référence à ces valeurs, ou à en faire des arguments à une fonction. Utilisez la classe de base FastAPI BaseModel et les structures de données Python telles que les objets Enum, NamedTuple et DataClasses pour préciser les arguments à nos procédures et appels API. Il est également bon de rendre nos paramètres et hyperparamètres de modèle configurables et non figés dans le code, ce qui permet de définir différentes configurations chaque fois que nous entraînons ou exécutons notre modèle.

Dans les projets d'apprentissage automatique, l'entraînement de notre modèle dépend beaucoup de notre problème, des données d'entrée et du format. En raison des multiples itérations d'entraînement que nos modèles suivent, il est bon d'intégrer le code d'entraînement à une interface API qui pourrait être réutilisable. Par exemple, au lieu de simplement créer un code qui traite nos copies locales des fichiers d'entrée, nous pourrions traduire le même principe pour accepter une seule adresse URL pointant vers un fichier compressé contenant tous les ensembles de données, en suivant une structure particulière. Les autres ensembles de données pourraient suivre la même structure et être intégrés à notre entraînement en utilisant le même code. Avant de créer notre structure d'intégration des ensembles de données, il est préférable de chercher des ensembles de données publics pertinents à notre problème et de réutiliser leur format d'entrée dans la mesure du possible. La normalisation de nos ensembles de données est une autre façon positive de créer un code d'apprentissage automatique modulaire.

Pensez toujours à la façon dont nous aimerions utiliser la solution avant de la programmer. Lorsque vous créez des interfaces API ou des modules, pensez du point de vue de l'utilisateur et non du point de vue du développeur. Au fur et à mesure que la science des données progresse, on continue de produire des ressources sur la façon d'améliorer la modularité des codes Python et les compétences en génie.

Conclusion

Dans cet article, nous avons présenté cinq pratiques de génie logiciel qui nous permettent de déployer des projets d'apprentissage automatique en exécutant notre modèle en tant que service Web axé sur REST. Nous abordons la pertinence du contrôle des versions des codes, de la documentation, des interfaces API REST, de la mise en conteneur et de la modularisation des codes comme étapes fondamentales à suivre dans votre CVDL. L'application de bonnes pratiques de développement logiciel et les outils mentionnés dans cet article amélioreront votre projet, votre collaboration en matière de code et le déploiement. Ce ne sont pas les seules bonnes pratiques sur lesquelles nous devrions nous concentrer, mais il s'agit d'un bon point de départ. Pour cet article, nous avons créé un modèle de projet de base suivant les pratiques mentionnées dans le présent article. N'hésitez pas à fourcher et réutiliser le modèle pour vos projets d'apprentissage automatique.

Par : Benoit Deshaies, Secrétariat du Conseil du Trésor du Canada; Dawn Hall, Secrétariat du Conseil du Trésor du Canada

Les systèmes décisionnels automatisés sont des systèmes informatiques qui automatisent une partie ou la totalité d'un processus décisionnel administratif. Ces technologies ont des fondements dans les statistiques et l'informatique, et peuvent comprendre des techniques comme l'analyse prédictive et l'apprentissage automatique.

La Directive sur la prise de décisions automatisée (« la Directive ») du Conseil du Trésor est un instrument de politique obligatoire qui s'applique à la plupart des institutions fédérales, à l'exception notable de l'Agence du revenu du Canada (ARC). Elle ne s'applique pas aux autres ordres de gouvernements, comme les gouvernements provinciaux ou municipaux. La Directive appuie la Politique sur les services et le numérique du Conseil du Trésor, et énonce les exigences auxquelles doivent satisfaire les institutions fédérales pour assurer l'utilisation responsable et éthique des systèmes décisionnels automatisés, y compris ceux qui utilisent l'intelligence artificielle (IA).

Les scientifiques des données jouent un rôle important dans l'évaluation de la qualité des données et la mise au point de modèles pour appuyer les systèmes décisionnels automatisés. Une compréhension du moment où la Directive s'applique et de la manière de satisfaire à ses exigences peut appuyer l'utilisation éthique et responsable de ces systèmes. En particulier, l'exigence en matière d'explication et l'orientation (Ligne directrice sur les services et le numérique, section 4.5.3 ) du Secrétariat du Conseil du Trésor du Canada (SCT) sur la sélection des modèles sont d'une grande importance pour les scientifiques des données.

Problèmes potentiels liés aux décisions automatisées

L'utilisation de systèmes décisionnels automatisés peut présenter des avantages et des risques pour les institutions fédérales. Les biais et le manque d'explicabilité sont deux domaines où des problèmes peuvent survenir.

Biais

Au cours des dernières années, les scientifiques de données ont pris de plus en plus conscience des biais ou « préjugés » de certains systèmes décisionnels automatisés, qui peuvent entraîner une discrimination. L'analyse fondée sur les données et l'apprentissage automatique peuvent capturer avec précision les résultats désirables et indésirables du passé et les projeter dans l'avenir. Les algorithmes fondés sur des données historiques peuvent, dans certains cas, amplifier les inégalités du passé touchant la race, la classe, le genre et d'autres caractéristiques. De plus, les algorithmes créés en fonction des jeux de données avec une représentation insuffisante ou disproportionnée peuvent avoir une incidence sur l'exactitude des systèmes. Par exemple, de nombreux systèmes de reconnaissance faciale ne fonctionnent pas aussi bien pour les personnes selon la couleur de leur peau ou leur sexe^{Note de bas de page 1},^{Note de bas de page 2}. Un autre exemple courant est le modèle facilitant le recrutement élaboré par Amazon, qui favorisait de manière disproportionnée les candidats masculins. Le problème sous-jacent était que le modèle avait été créé à l'aide des curriculum vitæ des candidats des technologies précédents à Amazon, qui étaient principalement des hommes^{Note de bas de page 3},^{Note de bas de page 4}.

Manque d'explicabilité

Un autre problème potentiel avec les systèmes automatisés est celui de l'impossibilité d'expliquer la façon dont le système est arrivé à ses prédictions ou à ses classifications. En particulier, il peut être difficile de produire une explication facile à comprendre lorsque les systèmes deviennent de plus en plus complexes, comme lorsque les réseaux neuronaux sont utilisés^{Note de bas de page 5}. Dans le contexte du gouvernement fédéral, il est essentiel d'être en mesure d'expliquer la façon dont les décisions administratives sont prises. Les personnes qui se voient refuser des services ou des prestations ont droit à une explication raisonnable et compréhensible de la part du gouvernement, ce qui va au-delà de l'indication qu'il s'agit d'une décision prise par un ordinateur. Un exemple éloquent de ce problème est survenu lorsqu'un algorithme a commencé à réduire le nombre de soins médicaux reçus par les patients, ce qui a eu des conséquences sur la santé et le bien-être des personnes. Dans ce cas, les utilisateurs du système n'étaient pas en mesure d'expliquer la raison pour laquelle cette réduction s'est produite^{Note de bas de page 6}.

Objectifs de la Directive

Les problèmes décrits ci-dessus sont atténués dans le cadre de la prise de décisions conventionnelle (« humaine ») par des lois. La Charte canadienne des droits et libertés définit les droits à l'égalité et interdit la discrimination. Les principes fondamentaux du droit administratif de la transparence, de la responsabilité, de la légalité et de l'équité procédurale définissent la manière dont les décisions doivent être prises et les explications fournies aux personnes touchées. La Directive interprète ces principes et protections dans le contexte des solutions numériques qui prennent ou recommandent des décisions.

La Directive vise également à s'assurer que les systèmes décisionnels automatisés sont déployés d'une manière qui permet de réduire les risques pour les Canadiens et les institutions fédérales, et qui donne lieu à une prise de décisions plus efficace, exacte et conforme, qui peut être interprétée. Elle le fait en exigeant : une évaluation de l'incidence des algorithmes, des mesures d'assurance de la qualité pour les données et l'algorithme, et des révélations proactives sur la façon d'utiliser les algorithmes et le contexte dans lequel ils sont utilisés, pour appuyer la transparence.

Portée de la Directive

La Directive s'applique aux systèmes décisionnels automatisés utilisés pour les décisions qui ont une incidence sur les droits juridiques, privilèges ou intérêts des personnes ou des entreprises à l'extérieur du gouvernement, par exemple, l'admissibilité aux prestations ou la sélection de personnes qui feront l'objet d'une vérification. La Directive est entrée en vigueur le 1^er avril 2019 et s'applique aux systèmes achetés ou développés après le 1^er avril 2020. Les systèmes existants ne sont pas tenus de se conformer, sauf si une décision automatisée est ajoutée après cette date.

La prise de conscience de la portée et de l'applicabilité de la Directive peut permettre aux scientifiques des données et à leurs superviseurs d'appuyer leur organisation dans la mise en œuvre des exigences de la Directive afin de permettre une utilisation éthique et responsable des systèmes.

Par exemple, il est important de prendre note que la Directive s'applique à l'utilisation de toute technologie, et non seulement à l'intelligence artificielle ou à l'apprentissage automatique. Cela comprend les systèmes numériques qui prennent ou recommandent des décisions, peu importe la technologie utilisée. Les systèmes automatisant les calculs ou mettant en œuvre les critères qui ne nécessitent pas ou ne remplacent pas le jugement pourraient être exclus, si ce qu'ils automatisent est entièrement défini dans les lois ou règlements, comme la limitation de l'admissibilité d'un programme aux personnes de 18 ans et plus. Toutefois, des systèmes apparemment simples pourraient être dans les limites de la portée s'ils sont conçus pour remplacer ou automatiser le jugement. Par exemple, un système qui appuie la détection de fraudes possibles en sélectionnant des cibles pour les inspections à l'aide d'indicateurs simples, comme une personne qui effectue des dépôts dans trois institutions financières différentes ou plus au cours d'une semaine donnée (un jugement de « comportement suspect »), pourrait être dans les limites de la portée.

La Directive s'applique aux systèmes qui formulent ou qui aident à formuler des recommandations ou des décisions. Demander à une personne de prendre la décision définitive n'élimine pas la nécessité de se conformer à la Directive. Par exemple, les systèmes qui fournissent des renseignements aux agents qui prennent les décisions définitives pourraient être dans les limites de la portée. Il existe plusieurs façons dont les algorithmes peuvent formuler ou aider à formuler des recommandations ou des décisions. La liste ci-dessous illustre certaines de ces façons, ce qui montre la façon dont l'automatisation des aspects du processus d'établissement des faits ou d'analyse peut influencer les décisions subséquentes.

Exigences de la Directive

Les exigences suivantes de la Directive sont fondamentales pour permettre l'utilisation éthique et responsable des systèmes décisionnels automatisés. Chaque section comprend une brève description de l'exigence et des exemples pertinents qui peuvent permettre leur mise en œuvre.

Évaluation de l'incidence algorithmique

Il est important de comprendre et de mesurer l'incidence de l'utilisation de systèmes décisionnels automatisés. L'outil d'évaluation de l'incidence algorithmique (EIA) est conçu pour aider les institutions fédérales à mieux comprendre et gérer les risques liés aux systèmes décisionnels automatisés. La Directive exige que l'on réalise une EIA avant la production et lorsqu'on apporte un changement à la fonctionnalité du système.

L'EIA fournit le niveau d'incidence d'un système fondé sur les réponses fournies par les institutions fédérales à un certain nombre de questions relatives aux risques et à l'atténuation, dont bon nombre sont d'une grande importance pour les scientifiques des données et leurs superviseurs. Cela comprend les questions sur les risques liés à l'algorithme, à la décision, à la source et au type de données ainsi que des efforts d'atténuation, comme la consultation et la détermination des processus et des procédures en place pour évaluer la qualité des données.

Le résultat de l'EIA attribue un niveau d'incidence allant du niveau I (faible incidence) au niveau IV (incidence très élevée). Par exemple, un système simple qui détermine l'admissibilité d'une remise de 2 $ pour l'achat d'une ampoule à faible consommation d'énergie pourrait être de niveau I, alors qu'un réseau neuronal complexe comprenant plusieurs sources de données qui décident d'accorder la libération conditionnelle à un prisonnier serait de niveau IV. L'évaluation de l'incidence comporte plusieurs volets et a été établie par l'entreprise de consultations avec les milieux universitaires, la société civile et d'autres institutions publiques.

Le niveau d'incidence déterminé par l'EIA appuie l'objectif de la Directive d'établir la correspondance des exigences appropriées au type d'application en cours de conception. Bien que certaines exigences de la Directive s'appliquent à tous les systèmes, d'autres varient en fonction du niveau d'incidence. Cela garantit que les exigences sont proportionnelles à l'incidence potentielle du système. Par exemple, les décisions dont le niveau d'incidence est de I peuvent être entièrement automatisées, alors qu'au niveau IV, la décision définitive doit être prise par une personne. Cela appuie les exigences de la Directive « Assurer une intervention humaine » pour une prise de décisions plus efficace.

Enfin, la Directive exige la publication des résultats définitifs de l'EIA sur le Portail du gouvernement ouvert – une importante mesure de transparence. Il sert de registre des systèmes décisionnels automatisés utilisés par le gouvernement, informe le public des moments où les algorithmes sont utilisés et fournit des renseignements de base sur leur conception et les mesures d'atténuation qui ont été prises pour réduire les résultats négatifs.

Transparence

La Directive comporte un certain nombre d'exigences visant à assurer la transparence de l'utilisation des systèmes décisionnels automatisés par les institutions fédérales. Comme mentionné ci-dessus, la publication de l'EIA sur le Portail du gouvernement ouvert sert de mesure de transparence. Étant donné que les clients consultent rarement ce Portail avant d'accéder aux services, la Directive exige également qu'un avis d'automatisation soit fourni aux clients par tous les modes de prestation de services utilisés (Internet, en personne, courrier ou téléphone).

Une autre exigence qui appuie la transparence, et qui est particulièrement pertinente pour les scientifiques des données, est l'obligation de fournir « une explication significative aux personnes concernées sur la façon dont la décision a été prise et la raison pour laquelle elle a été prise ». Il a été mentionné ci-dessus que certains algorithmes complexes sont plus difficiles à expliquer, ce qui rend cette exigence plus difficile à satisfaire. Dans son orientation, le SCT privilégie les « modèles facilement interprétables » et « le modèle le plus simple qui fournira le rendement, l'exactitude, l'interprétabilité et l'absence de partialité nécessaires » en faisant la distinction entre l'interprétabilité et l'explicabilité (Ligne directrice sur les services et le numérique, section 4.5.3). Elle s'harmonise avec les travaux d'autres intervenants qui portent sur l'importance de modèles interprétables, comme Rudin^{Note de bas de page 7} et Molnar^{Note de bas de page 8}.

De même, lorsque le code source appartient au gouvernement du Canada, il doit être publié en tant que source libre, dans la mesure du possible. En ce qui concerne les systèmes propriétaires, la Directive exige que toutes les versions du logiciel soient protégées, que le gouvernement du Canada détienne le droit d'accéder au logiciel et d'effectuer des essais sur celui-ci, et d'autoriser des tiers à examiner et à vérifier les composants, au besoin.

Au-delà de la publication du code source, des mesures de transparence supplémentaires favorisent la communication de l'utilisation de systèmes décisionnels automatisés à un large public. Plus précisément, aux niveaux d'incidence III et IV, la Directive exige la publication d'une description en langage clair de la façon dont le système fonctionne, notamment la façon dont il appuie la décision et les résultats de tout examen ou vérification. Ce dernier peut comprendre les résultats de l'Analyse comparative entre les sexes plus, de l'évaluation des facteurs relatifs à la vie privée et des examens par les pairs, entre autres.

Assurance de la qualité

L'assurance de la qualité joue un rôle essentiel dans le développement et l'ingénierie de tout système. La Directive prévoit une exigence pour les essais avant la production, qui est une mesure d'assurance qualité standard. Toutefois, compte tenu de la nature unique des systèmes décisionnels automatisés, la Directive exige également l'élaboration de processus permettant de tester les données pour déceler les biais imprévus qui peuvent avoir une incidence inéquitable sur les résultats et de s'assurer que les données sont pertinentes, exactes et à jour.

Les efforts d'assurance de la qualité doivent se poursuivre après le déploiement du système. L'exploitation du système doit comprendre des processus pour surveiller les résultats selon un calendrier, afin de se protéger contre les résultats imprévus. La fréquence de ces vérifications peut dépendre d'un certain nombre de facteurs, comme l'incidence des décisions et la quantité de décisions, et la conception du système. Les systèmes d'apprentissage qui sont fréquemment recyclés peuvent nécessiter une surveillance plus intense.

Il existe également la participation directe des humains à l'assurance de la qualité, comme la nécessité de consulter les services juridiques, d'assurer une intervention humaine pour les décisions ayant des niveaux d'incidence supérieurs (une mesure souvent appelée « maillon humain ») et d'assurer une formation suffisante pour tous les employés qui développent, exploitent et utilisent le système.

Enfin, la Directive exige un examen par les pairs de la part d'un tiers qualifié. L'objectif de cet examen est de valider l'évaluation de l'incidence algorithmique, la qualité du système, la pertinence des mesures d'assurance de la qualité et d'atténuation des risques, et de déterminer le risque résiduel de l'exploitation du système. Le rapport sur l'examen par les pairs doit être examiné par les fonctionnaires avant de prendre la décision d'exploiter le système. Une collaboration entre le SCT, l'École de la fonction publique du Canada et l'Université d'Ottawa a donné lieu à un guide proposant des pratiques exemplaires dans le cadre de cette activité^{Note de bas de page 9}.

Conclusion

L'automatisation de la prestation des services par le gouvernement peut avoir une incidence profonde et grave, tant positive que négative. L'adoption de technologies axées sur les données offre une occasion unique d'examiner et de corriger les préjugés et les inégalités du passé afin de promouvoir une société plus inclusive et équitable. Les scientifiques de données ont également constaté que les systèmes décisionnels automatisés peuvent présenter certains problèmes relatifs aux biais et au manque d'explicabilité. La Directive du Conseil du Trésor sur la prise de décisions automatisée fournit un ensemble complet d'exigences qui peuvent servir de cadre de base pour l'automatisation responsable des services et la préservation de la protection de base du droit dans le monde numérique. En droit administratif, le degré d'équité procédurale dans un processus décisionnel donné augmente ou diminue en fonction de l'importance de la décision. De même, les exigences de la Directive s'échelonnent selon le niveau d'incidence calculé par l'évaluation de l'incidence algorithmique.

Les scientifiques des données de la fonction publique fédérale peuvent jouer un rôle de premier plan dans la transformation du gouvernement. En appuyant la Directive en veillant à ce que les décisions soient efficaces, exactes, cohérentes et interprétables, les scientifiques des données ont la possibilité de trouver des moyens d'améliorer et d'optimiser la prestation des services et des programmes. Les Canadiens ont également besoin de scientifiques des données pour diriger les efforts visant à repérer les biais imprévus dans les données et pour appuyer l'adoption responsable de l'automatisation par l'élaboration de modèles interprétables en assurant la transparence, l'équité et l'explicabilité nécessaires.

Note : Restez à l'affût puisqu'il y aura un article prochainement sur le Cadre pour l'utilisation des processus d'apprentissage automatique de façon responsable de Statistique Canada. Le Réseau de la sciences des données est d'ailleurs intéressé à recevoir des propositions d'articles supplémentaires sur ce sujet. N'hésitez pas à nous en envoyer!

Membres de l'équipe

Benoit Deshaies, Dawn Hall

Par : Chatana Mandava, Statistique Canada

Un tableau de bord est une représentation visuelle des renseignements les plus importants nécessaires à la réalisation d'un ou de plusieurs objectifs. On regroupe et organise ces renseignements sur un seul écran afin de pouvoir en prendre connaissance en un seul coup d'œil. Les tableaux de bord jouent un rôle essentiel dans le domaine de la science des données, car ils sont l'un des moyens les plus efficaces de résumer des résultats et de les communiquer aux utilisateurs. Les analystes de Statistique Canada passent souvent leur temps à chercher des renseignements parmi les données fournies ou à tirer manuellement des conclusions à partir de ces données. La présentation de tableaux de bord conviviaux et interactifs réduit la charge de travail des analystes, car ils sont en mesure d'extraire des renseignements pertinents simplement à l'aide de filtres. Les tableaux de bord sont un puissant moyen de présenter les renseignements qui peuvent servir à observer les tendances et à faire le suivi du rendement des modèles, pour faciliter la prise de décisions au sein d'une organisation. Lorsqu'ils sont bien présentés, les tableaux de bord augmentent la productivité des utilisateurs en réduisant l'ampleur des renseignements à analyser. En revanche, s'ils sont mal présentés, ils peuvent transformer la recherche de renseignements pertinents en une entreprise colossale.

De nombreux outils, notamment Tableau, Power BI, Dash Plotly (en anglais seulement) et Kibana, peuvent servir à créer un tableau de bord efficace et interactif. Le choix de l'outil dépend de nombreux facteurs comme le type de données (p. ex. des données de type texte, des données numériques), la taille des données, les paramètres ainsi que les besoins des utilisateurs. Le présent article permet d'examiner les exemples de deux énoncés de problèmes différents et de deux tableaux de bord créés sur la base de leurs exigences.

Tableaux de bord créés à l'aide d'Elasticsearch et de Kibana

Dans le cadre d'un projet récent, des scientifiques des données de Statistique Canada avaient pour mandat de créer un tableau de bord permettant de visualiser les articles de presse portant sur la COVID-19 et de les filtrer en fonction des critères suivants : le nom de l'entreprise, le nom de la source, le nom de la source d'extraction et la date, et en fonction de quelques mots clés importants comme « COVID » et « équipement de protection individuelle ». Les données extraites pour résoudre ce problème étaient de type texte. Des millions d'articles de presse ont été extraits par moissonnage du Web et divers autres moyens. Plusieurs modèles d'apprentissage automatique et d'apprentissage profond, comme les machines à vecteurs de support (SVM) et les représentations d'encodeur bidirectionnel à partir de transformateurs (BERT), ont été appliqués pour classer les articles de presse. La façon optimale d'afficher les résultats regroupés consistait à produire un tableau de bord interactif. Dans le cadre de ce projet, un tableau de bord Kibana a été créé afin d'afficher tous les articles de presse et des représentations visuelles des résultats.

Elasticsearch est un moteur de recherche fondé sur la bibliothèque Lucene (en anglais seulement). Il permet le stockage d'énormes volumes de données et permet aux utilisateurs d'effectuer rapidement des recherches parmi les données et d'obtenir des résultats en quelques millisecondes. Au lieu d'effectuer une recherche directement dans le texte, Elasticsearch parcourt un index et génère des résultats en peu de temps. Kibana est un outil de visualisation et de gestion conçu pour Elasticsearch. Compte tenu de l'objectif du projet, Kibana a été choisi comme étant l'outil le plus approprié. Cet outil comporte de nombreuses fonctionnalités intéressantes pour les utilisateurs, notamment celle de créer des histogrammes, des graphiques circulaires, des graphiques à barres, des cartes géographiques et ainsi de suite. De plus, l'interactivité est gérée automatiquement dans l'outil. Il existe de nombreux autres outils de visualisation (p. ex. Vega ou Timelion) qui peuvent aider à créer des visualisations de données agrégées. Une autre fonctionnalité intéressante de Kibana est la possibilité de personnaliser les visualisations. Grâce à la nouvelle composante Vega, les utilisateurs peuvent créer une variété de visualisations des données accessibles à partir de la bibliothèque Vega. Ces données peuvent être intégrées dans Elasticsearch à l'aide d'une bibliothèque Python. L'objectif principal derrière l'utilisation de la bibliothèque Python d'Elasticsearch est d'accéder aux articles de presse et de les stocker dans Elasticsearch à des fins de recherche et d'analyse. Les données sont extraites puis intégrées dans Elasticsearch grâce à la création d'un schéma rigoureux ou d'une mise en correspondance, ce qui permet d'assurer leur indexation selon le format et le modèle appropriés. L'interrogation peut être effectuée une fois l'enregistrement indexé.

Les options intégrées dans le tableau de bord de Kibana ont été utilisées pour créer un tableau de bord interactif à partir d'articles de presse. Sur une période d'environ 10 jours, un graphique chronologique a été créé pour analyser le nombre total d'articles extraits au cours de cette période. Il s'agit d'un graphique chronologique interactif dans lequel les utilisateurs peuvent cliquer sur n'importe quelle année afin que les articles soient filtrés automatiquement en fonction du choix. L'option « tableau » a été utilisée pour la visualisation du titre et du corps de l'article, du fragment, de la source d'extraction, du nom de l'entreprise, et du nom de la source et du média qui a publié ces articles de presse. Toutes les fonctions de filtre requises ainsi que certaines visualisations de données agrégées ont été incluses dans le tableau de bord. Quelques autres fonctionnalités, comme les nuages de mots, ont également été ajoutées, ce qui a aidé les analystes à comprendre les mots importants dans les articles de presse et à filtrer les articles pertinents en fonction de ces mots. En fait, ces mots changent lorsqu'on applique des filtres, et de nouveaux ensembles de mots apparaissent selon les articles présélectionnés. Une de ces fonctionnalités permet aux utilisateurs d'enregistrer les résultats dans un fichier CSV, au cas où l'analyste aurait besoin d'intégrer d'autres outils pour réaliser une analyse plus poussée. Les utilisateurs peuvent également partager le tableau de bord avec d'autres personnes en leur envoyant une adresse URL.

La fonctionnalité « modèles d'indexation » de Kibana permet de modifier les modèles d'indexation et de mettre à jour le champ correspondant. Un modèle d'indexation sert à définir les propriétés d'un champ. Par exemple, lorsque les données sont intégrées dans la base de données, peu de champs deviennent consultables, et quelques champs peuvent être regroupés. Le modèle d'indexation permet aux utilisateurs d'activer ces fonctionnalités pour tous les champs. Dans le cas mentionné ci-dessus, il y a un champ comprenant l'adresse URL des articles. Au moment de l'intégration, le format de ce champ URL est passé à un format texte. Le format a été modifié en une adresse URL cliquable grâce à un modèle d'indexation.

Dash Plotly

Dans un autre exemple d'utilisation de tableaux de bord, un deuxième projet de Statistique Canada a consisté à trouver des événements à partir d'articles de presse. En travaillant avec des utilisateurs sur une période de 35 jours, les résultats finaux ont été affichés dans un tableau de bord produit à l'aide de Dash Plotly. Dash est un outil à accès libre conçu par Plotly pour créer des applications Web d'apprentissage automatique et de science des données. Comme la mise en page de Dash est en langage HTML, les utilisateurs peuvent intégrer divers gadgets logiciels, en choisissant leur disposition et leur style.

Ce tableau de bord comprend également un tableau qui affiche les articles de presse, un résumé d'autres articles, des boutons interactifs pour passer d'un article à l'autre, un graphique chronologique et un menu déroulant permettant de filtrer les articles en fonction du nom de l'entreprise, de la date et de la division. Dash ne compte pas le même nombre de fonctions intégrées que Kibana; il est conçu pour offrir un degré de fonctionnalité plus limité pour la création d'applications Web personnalisées. Avec Dash Plotly, les utilisateurs peuvent mettre en évidence l'emplacement, l'organisation, la date et l'heure dans les articles de presse. Tout le script du tableau de bord est écrit en langage Python, ce qui signifie que l'on doit y accorder une attention particulière si l'on souhaite diffuser ce tableau à l'extérieur de l'organisation.

Choix de l'approche en fonction des besoins de l'utilisateur final

Bien que cet article ait traité de la création de tableaux de bord à l'aide de Kibana et de Dash Plotly, il existe de nombreux autres tableaux de bord interactifs qui peuvent être construits à l'aide de divers outils. Les deux projets abordés permettent d'exploiter des systèmes infonuagiques, mais il existe aussi des outils sur ordinateurs que l'on peut connecter à des systèmes moins exigeants. Kibana et Plotly offrent tous les deux des systèmes flexibles, mais ils s'intègrent aux flux de travail de différentes façons. Elasticsearch est fortement axé sur l'indexation et la recherche de texte à haute performance, ce qui en fait un bon choix pour traiter de grandes quantités de données textuelles. Dash Plotly intègre toute la puissance et la commodité de la bibliothèque Pandas pour la manipulation des données. L'outil que vous choisissez d'utiliser dépend fortement du contexte et des exigences de votre projet ainsi que des besoins des utilisateurs finaux.

Par : Yadvinder Bhuller, Santé Canada; Keith O’Rourke, Santé Canada

Malgré un nombre croissant d'exemples où des modèles de prévision simples et complexes ont été utilisés pour la prise de décisions, la précision des prévisions demeure pertinente pour les deux types de modèles. En outre, plus un modèle est complexe, moins il est susceptible d'être utilisé par des utilisateurs débutants qui ne maîtrisent pas tout à fait l'apprentissage automatique. Quand on tente de maximiser l'exactitude prédictive d'un modèle, sans tenir compte de la difficulté, pour une personne, d'anticiper les prévisions à partir de données d'entrée, cela peut donner lieu à des modèles de prévision complexes. Cependant, même avec une méthode aussi simple que la régression linéaire, la complexité augmente à mesure que d'autres variables et leurs interactions sont ajoutées. À l'autre extrême, lorsque de nombreuses fonctions non linéaires, comme celles des réseaux neuronaux, sont utilisées pour faire des prévisions, les résultats pourraient être trop complexes pour être compris. Ces modèles sont habituellement appelés modèles de prévision de type « boîte noire ». Les modèles précis et interprétables peuvent être de diverses natures. Il peut s'agir de listes de règles et d'arbres de décision précis qui sont tellement concis, qu'ils peuvent être entièrement décrits en une phrase ou deux pour les données tabulaires. Il peut aussi s'agir de modèles additifs généralisés modernes (p. ex. pour le traitement des dossiers médicaux relativement complexes) ou de méthodes pour dénouer les réseaux neuronaux convenant au traitement des données non structurées comme les pixels. Un ajout notable récent est l'utilisation de l'apprentissage bayésien non supervisé à contrainte peu complexe appliqué aux couches profondes d'une structure latente, qui est ensuite utilisé pour établir une liste concise de règles avec une grande précision (Gu et Dunson, 2021).

Un premier exemple, qui date de plus de 20 ans, d'une méthode simple qui fournit des prévisions aussi précises que des modèles plus complexes est l'étude d'Ennis et coll., réalisée en 1998, de diverses méthodes d'apprentissage automatique qui reposent sur la base de données GUSTO-I où aucune de ces méthodes n'a pu surpasser un modèle de régression logistique relativement simple. Des comptes rendus plus récents de méthodes complexes, même si des méthodes simples auraient pu suffire, sont présentés dans l'article de 2019 de Rudin et Radin. Une solution simple souvent suggérée pour réduire cette complexité ingérable consiste à trouver des façons d'expliquer le fonctionnement de ces modèles de type « boîte noire ». Cependant, ces explications ne tiennent pas toujours compte de renseignements fondamentaux. Par conséquent, plutôt que d'être directement liées à ce qui se passe dans un modèle de type « boîte noire », elles deviennent des « histoires » visant à obtenir des prévisions concordantes. Comme la concordance n'est pas parfaite, elles peuvent entraîner des résultats très trompeurs dans de nombreuses situations.

Il faudrait peut-être une plus grande sensibilisation au nombre croissant de techniques permettant d'élaborer des modèles simples et interprétables à partir de rien, et qui atteignent une grande précision. Les techniques ne sont pas de simples améliorations de la régression linéaire ou logistique (arrondissement des coefficients à des nombres entiers, ce qui conduit à une perte de précision), mais exigent une sélection de contraintes appropriées au domaine et de nouvelles méthodes d'optimisation sous contraintes. Il en résulte un éventail de possibilités d'interprétation simple dans le cadre de diverses applications.

Comprendre où et quand être simple!

Même si nous devons accepter ce que nous ne comprenons pas, il ne faut jamais oublier les avantages que nous pouvons tirer de ce que nous comprenons. Par exemple, nous ne comprendrons peut-être jamais pleinement le monde physique. Ni la façon dont les gens pensent, interagissent, créent et décident. En matière d'apprentissage automatique, dans un entretien diffusé sur YouTube en 2018 (en anglais seulement), Geoffrey Hinton a attiré l'attention sur le fait que les gens sont incapables d'expliquer exactement de quelle manière ils décident en général si quelque chose correspond au chiffre 2 ou non. Ce fait a été souligné à l'origine, il y a quelque temps déjà, par Herbert Simon, et n'a pas été sérieusement contesté depuis (Erickson et Simon, 1980). Cependant, les modèles de prévision ne sont que des abstractions et nous pouvons comprendre les abstractions créées pour représenter cette réalité, qui est complexe et à laquelle nous ne pouvons souvent pas accéder directement. Par conséquent, l'incapacité à comprendre les gens n'est pas une raison valable pour résister à l'envie de comprendre les modèles de prévision.

Essentiellement, les abstractions sont des diagrammes ou des symboles qui peuvent être manipulés, sans erreur, pour discerner leurs enjeux. Généralement appelées modèles ou hypothèses, elles sont déductives et peuvent être comprises en elles-mêmes en raison de ce qu'elles supposent. Du moins, jusqu'à ce qu'elles deviennent trop complexes. Par exemple, les triangles sur un plan sont compris par la plupart des gens, tandis que les triangles sur une sphère le sont moins. La réalité peut toujours être trop complexe, mais les modèles qui la représentent adéquatement dans un certain but ne doivent pas nécessairement l'être. Les triangles sur un plan permettent la navigation à courte distance, alors que sur une sphère, ils la permettent à longue distance. En clair, c'est le modèle abstrait qui est compris et pas nécessairement la réalité qu'il tente de représenter.

Cependant, pour une raison ou une autre, une idée fausse et persistante, selon laquelle les modèles permettant des prévisions précises doivent généralement être complexes, s'est développée dans le domaine de l'apprentissage automatique. Des exemples montrent que dans certains domaines d'application, les modèles simples n'atteignent pas encore une précision comparable à celle des modèles de type « boîte noire ». D'autre part, des modèles simples permettent toujours de faire des prévisions aussi précises que celles de n'importe quel modèle de type « boîte noire » à la fine pointe de la technologie et, par conséquent, la question qui se pose, comme l'indique l'article de 2019 de Rudin et Radin, est la suivante : « Pourquoi utilisons-nous des modèles de type « boîte noire » en intelligence artificielle alors que ce n'est pas nécessaire? ».

Ne pas utiliser des modèles simples dans des domaines d'application où leur précision est suffisante a inutilement mené à des recommandations qui peuvent avoir des incidences sur des domaines comme la société, la santé, la liberté et la sécurité. Le problème du choix hypothétique souvent évoqué entre la fiabilité d'un robot chirurgien qui repose sur l'apprentissage automatique et un chirurgien humain moins fiable ne se pose plus lorsqu'on construit un robot chirurgien interprétable aussi fiable que tout autre robot. Encore une fois, c'est le modèle de prévision qui est compréhensible, pas nécessairement la tâche de prévision elle-même.

Des modèles simples et interprétables?

Le nombre de domaines d'application dans lesquels des modèles de prévision simples et précis peuvent être conçus pour être compris a augmenté au fil du temps. On pourrait soutenir que ces modèles devraient être étiquetés comme modèles d'apprentissage automatique « interprétables », car ils sont conçus à partir de rien pour être compréhensibles. Ils sont délibérément soumis à des contraintes pour que leurs processus de raisonnement soient plus compréhensibles pour la plupart, voire la totalité des utilisateurs humains. Non seulement de tels modèles rendent le lien entre les données d'entrée et les prévisions presque évident, il est plus facile d'y détecter les problèmes et de les résoudre, et d'y apporter des modifications au besoin. L'interprétabilité est au cœur du domaine et les contraintes peuvent comprendre les éléments suivants :

• la rareté du modèle;
• la monotonie par rapport à une variable;
• la décomposition en sous-modèles;
• la capacité à effectuer un raisonnement basé sur des cas;
• la clarification de certains types d'information dans le processus de raisonnement du modèle;
• les contraintes génératives (p. ex. les processus biologiques);
• les  préférences parmi le choix des variables;
• tout autre type de contrainte pertinent au domaine.

Parmi les exemples notables de modèles interprétables, citons les modèles à logique éparse (comme les arbres de décision, les listes de décision et les ensembles de décision) et les systèmes de notation, qui sont des modèles de classification linéaire exigeant des utilisateurs qu'ils se limitent à additionner, à soustraire et à multiplier quelques petits nombres seulement pour faire une prévision. Ces modèles peuvent être beaucoup plus faciles à comprendre que la régression multiple et la régression logistique, qui peuvent être difficiles à interpréter. Cependant, la simplification intuitive de ces modèles de régression par limitation du nombre de prédicteurs, et l'arrondissement des coefficients n'offre pas une précision optimale. Il s'agit simplement d'un ajustement ultérieur. Il est préférable d'intégrer l'interprétabilité dès le départ.

La prise en compte de nombreux modèles de prévision possibles pour exécuter une tâche de prévision donnée est de mieux en mieux comprise. L'observation relativement fréquente de modèles simples donnant de bons résultats avec des données tabulaires (un ensemble de variables, dont chacune a sa propre signification) a été relevée il y a plus de 20 ans et a été qualifiée « d'effet Rashomon » (Breiman, 2001). Breiman a évoqué la possibilité d'utiliser un grand ensemble Rashomon dans de nombreuses applications, c'est-à-dire une multitude de modèles donnant approximativement le même taux d'erreur minimal. Un moyen simple de le vérifier consiste à adapter un certain nombre de modèles différents d'apprentissage automatique au même ensemble de données. Si un grand nombre d'entre eux est aussi précis que le plus précis (dans la marge d'erreur), alors beaucoup d'autres modèles non testés pourraient l'être aussi. Dans une étude récente (Semenova et coll., 2019), on suggère maintenant d'exécuter un ensemble de modèles différents d'apprentissage automatique (la plupart de type « boîte noire ») pour déterminer leur précision relative sur un ensemble de données particulier pour prédire l'existence d'un modèle interprétable simple et précis, c'est-à-dire un moyen de déterminer rapidement les applications pour lesquelles il y a de fortes chances que l'on puisse élaborer un modèle de prévision interprétable et précis.

Quelle est l'incidence du cycle de vie complet de la science des données sur l'apprentissage automatique?

Le compromis entre la précision et l'interprétabilité d'un premier ensemble de données fixes dans un domaine d'application pourrait ne pas demeurer valable dans le temps. En fait, on s'attend à ce qu'il change à mesure que des données s'accumulent, que le domaine d'application évolue ou soit mieux compris, que la collecte des données soit affinée ou que de nouvelles variables soient ajoutées ou définies. Dans le cadre d'un processus complet de la science des données, même lorsqu'on ne dispose que d'un premier ensemble de données, il convient d'évaluer et d'interpréter les résultats de façon critique et d'ajuster le traitement des données, la fonction de perte, la mesure d'évaluation ou tout autre élément pertinent. Transformer plus efficacement les données en connaissances accrues sur la tâche de prédiction qui peuvent ensuite être exploitées pour augmenter à la fois la précision et la généralisation probable. Tout compromis envisageable entre la précision et l'interprétabilité devrait donc être évalué dans le cadre du processus complet de la science des données et du cycle de vie de l'apprentissage automatique.

Le processus complet de la science des données et du cycle de vie est probablement différent lorsque des modèles interprétables sont utilisés. Il faut obtenir davantage de commentaires de la part des experts du domaine pour produire un modèle interprétable qui leur semble acceptable. Cela devrait être considéré comme un avantage. Par exemple, il n'est pas inhabituel, à un stade donné, de trouver de nombreux modèles également interprétables et précis. Pour un scientifique des données, la sélection d'un modèle peut être ardue. Cependant, lorsque ces modèles sont présentés à des experts du domaine, ceux-ci peuvent facilement discerner des possibilités d'améliorer les contraintes et d'indiquer celles qui sont moins susceptibles de bien se généraliser. Tous les modèles interprétables et précis ne sont pas égaux aux yeux des experts du domaine.

Les modèles interprétables sont beaucoup plus fiables dans la mesure où l'on peut plus facilement discerner où et quand on peut leur faire confiance et de quelle façon. Mais comment peut-on le faire sans comprendre la façon dont le modèle fonctionne, surtout lorsqu'il n'est manifestement pas digne de confiance? Cela est particulièrement important dans les cas où la distribution sous-jacente des données change et qu'il est essentiel de procéder sans délai à la détection et la résolution de problèmes et à des modifications, comme l'indique l'article réalisée en 2020 de Hamamoto et coll (en anglais seulement). Il est sans doute beaucoup plus difficile de demeurer performant dans le cycle de vie complet de l'apprentissage automatique avec des modèles de type « boîte noire » qu'avec des modèles interprétables. Même pour les applications où les modèles interprétables ne sont pas encore assez précis, ces derniers peuvent être utilisés comme un outil pour faciliter le débogage des modèles de type « boîte noire ».

Explications erronées

Il existe aujourd'hui une documentation vaste et déroutante qui confond l'interprétabilité et l'explicabilité. Dans ce court blogue, le degré d'interprétabilité est simplement considéré comme la facilité avec laquelle l'utilisateur peut comprendre le lien entre les données d'entrée et ce que le modèle d'apprentissage automatique prédirait. Erasmus et coll. (2020) présentent un point de vue plus général et philosophique. Rudin et coll. (2021) évitent d'essayer de présenter une définition exhaustive en fournissant plutôt des principes directeurs généraux pour aider les lecteurs à éviter les façons courantes, mais problématiques, de penser à l'interprétabilité. D'autre part, le terme « explicabilité » renvoie souvent à des tentatives ultérieures pour expliquer une boîte noire en utilisant des modèles « de doublure » plus simples qui prédisent les prédictions de la boîte noire. Cependant, comme indiqué dans la Ligne directrice sur les services et le numérique du gouvernement du Canada (2021), la prévision n'est pas une explication, et lorsqu'elle est présentée comme une explication, elle peut gravement induire en erreur. Souvent, cette documentation suppose qu'il suffit d'expliquer le fonctionnement d'une boîte noire sans se demander s'il existe un modèle interprétable donnant la même précision, peut-être parce qu'on a cru, sans trop y réfléchir, que seuls les modèles trop complexes pour être compris peuvent atteindre une précision acceptable.

La prise de conscience croissante des risques associés à ces « explications » a conduit un groupe de chercheurs à étudier comment l'incompréhension peut être intentionnellement conçue, ce dont les organismes de réglementation devraient de plus en plus s'inquiéter (Lakkaraju et Bastani, 2019). Il n'est pas rare non plus que ceux qui font régulièrement de la modélisation en boîte noire expliquent que leurs modèles sont des solutions de rechange ou même qu'ils justifient de renoncer à l'apprentissage et au développement de modèles interprétables.

Simplifier les choses

Les modèles interprétables d'apprentissage automatique sont simples et l'on peut s'y fier lorsqu'on s'appuie sur des outils d'apprentissage automatique pour prendre des décisions. Par ailleurs, même l'interprétabilité n'est probablement pas requise pour les décisions qui peuvent être modifiées ou vérifiées ultérieurement par des « humains » (p. ex. suggérer des options). Malgré la soif de modèles simples et précis, il est important de remarquer que les apprentissages automatiques actuels ne peuvent pas égaler la précision des modèles de type « boîte noire » dans tous les domaines d'application. Pour les applications reposant sur des données brutes (pixels, ondes sonores, etc.), les réseaux neuronaux en boîte noire ont actuellement un avantage par rapport aux autres approches. En outre, les modèles de type « boîte noire » permettent aux utilisateurs de déléguer la responsabilité pour saisir les implications de l'adoption du modèle. Bien qu'un compromis nécessaire entre la précision et l'interprétabilité subsiste dans certains domaines d'application, son omniprésence reste une exagération et la prévalence de ce compromis pourrait continuellement diminuer à l'avenir. Dans le domaine de l'apprentissage automatique, cela a créé une situation où les possibilités de comprendre et de tirer parti des avantages sont souvent négligées. Par conséquent, les avantages des nouvelles techniques de modélisation interprétables devraient être pleinement pris en compte dans toute application d'apprentissage automatique, au moins pour déterminer si une précision adéquate est réalisable. Finalement, peut-être que cela pourrait se résumer au fait que si les choses simples fonctionnent, pourquoi les rendre plus complexes.

Membres de l'équipe : Keith O'Rourke (Agence de réglementation de la lutte antiparasitaire), Yadvinder Bhuller (Agence de réglementation de la lutte antiparasitaire).

Poursuivre l'apprentissage automatique...

Breiman, L. (2001). Statistical Modeling: The Two Cultures (with comments and a rejoinder by the author). Statist. Sci. 16(3): 199-231. DOI: 10.1214/ss/1009213726

Ennis, M., Hinton, G., Naylor, D., Revow, M., and Tibshirani, R. (1998). A Comparison of Statistical Learning Methods on the Gusto Database. Statistics. Med. 17, 2501-2508. A comparison of statistical learning methods on the GUSTO database (en anglais seulement)

Erasmus, A., Bruent, T.D.P., and Fisher E. (2020). What is Interpretability? Philosophy & Technology. What is Interpretability?

Ericsson, K. A., & Simon, H. A. (1980). Verbal reports as data. Psychological Review, 87(3), 215–251. Verbal reports as data.

Government of Canada. (2021). Guideline on Service and Digital. Guideline on Service and Digital. [Accessed: May 13, 2021].

Gu, Y., and Dunson, D.B. (2021). Identifying Interpretable Discrete Latent Structures from Discrete Data. arXiv:2101.10373 [stat.ME]

Hinton, G. (2018). Why Is a Two a Two? Why Is A Two A Two? With Geoffrey Hinton and David Naylor [Accessed: May 13, 2021]. (en anglais seulement)

Hamamoto, R., Suvarna, K., Yamada, M., Kobayashi, K., Shinkai, N., Miyake, M., Takahashi, M., Jinnai, S., Shimoyama, R., Sakai, A., Taksawa, K., Bolatkan, A., Shozu, K., Dozen, A., Machino, H., Takahashi, S., Asada, K., Komasu, M., Sese, J., and Kaneko., S. (2020). Application of Artificial Intelligence Technology in Oncology: Towards the Establishment of Precision Medicine. Cancers. 12(12), 3532; Application of Artificial Intelligence Technology in Oncology: Towards the Establishment of Precision Medicine (en anglais seulement)

Lakkaraju, H., and Bastani, O. (2019). "How do I fool you?": Manipulating User Trust via Misleading Black Box Explanations. arXiv:1911.06473 [cs.AI]

Rudin, C., Chen, C., Chen, Z., Huang, H., Semenova, L., and Zhong, C. (2021). Interpretable Machine Learning: Fundamental Principles and 10 Grand Challenges. arXiv:2103.11251 [cs.LG]

Rudin, C., & Radin, J. (2019). Why Are We Using Black Box Models in AI When We Don't Need To? A Lesson From An Explainable AI Competition. Harvard Data Science Review, 1(2). Why Are We Using Black Box Models in AI When We Don't Need To? A Lesson From An Explainable AI Competition

Semenova, R., Rudin, C., and Parr, R. (2019). A study in Rashomon curves and volumes: A new perspective on generalization and model simplicity in machine learning. arXiv:1908.01755 [cs.LG]