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]

• 1. Que signifient les résultats?

  1. Que signifient les résultats?

  Test de la tache de sang séché

  Positif — vous avez probablement été exposé au virus de la COVID-19 ou vous avez reçu le vaccin, et votre corps a produit des anticorps contre le virus.
  Négatif — aucune trace d'anticorps contre le virus de la COVID-19 n'a été trouvée dans votre sang.
  Peu concluant — le résultat de votre test ne nous permet pas de déterminer si vous avez des anticorps ou non contre le virus de la COVID-19. Un problème est peut-être survenu avec le test.

  PCR Test de salive

  Positif - L'ARN spécifique du virus SARS-CoV-2 responsable de l'infection par le COVID-19 a été détecté dans votre échantillon de salive.
  Négatif - L'ARN spécifique du virus SRAS-CoV-2 responsable de l'infection par le COVID-19 n'a pas été détecté dans votre salive.
  Non concluant - Le résultat de votre test ne nous permet pas de savoir si vous avez ou non de l'ARN spécifique du virus SRAS-CoV-2 responsable de l'infection par le COVID-19 dans votre salive. Cela peut être dû à un problème avec le test.

  Si vous avez des questions sur les résultats de votre test(s), veuillez-vous adresser à votre prestataire de soins de santé.

• 2. Si le résultat de mon test d'anticorps contre la COVID-19 et/ou PCR-salive est positif, dois-je faire quelque chose?

  2. Si le résultat de mon test d'anticorps contre la COVID-19 et/ou PCR-salive est positif, dois-je faire quelque chose?

  Test de la tache de sang séché 

  Non, vous n'avez rien à faire. Un résultat positif vous informe d'une infection qui s'est produite dans le passé ou que vous avez reçu le vaccin. Cela ne signifie pas que vous êtes infecté en ce moment. Veuillez continuer à respecter les mesures de santé publique.

  Test PCR salive
  - Un résultat positif vous informe d'une infection active par le COVID-19 au moment où vous avez fourni votre échantillon de salive. Même si vous avez obtenu un résultat négatif au test de dépistage du virus SRAS-CoV-2 qui cause l'infection par le COVID-19, vous devez suivre toutes les recommandations de la Santé publique sur la façon de vous protéger et de protéger les autres.

• 3. Quel est le degré de précision du test de la tache de sang séché?

  3. Quel est le degré de précision du test de la tache de sang séché?

  D'après notre expérience des tests effectués jusqu'à présent, les résultats positifs sont corrects environ 95 % du temps. Les résultats négatifs, quant à eux, sont corrects environ 99 % du temps. Aucun test de laboratoire n'est parfait.

• 4. Quel est l'avantage des anticorps contre la COVID-19?

  4. Quel est l'avantage des anticorps contre la COVID-19?

  À l'heure actuelle, nous en savons très peu sur les avantages des anticorps contre le virus de la COVID-19. Les experts ne sont pas sûrs de la durée de vie des anticorps ni de leur capacité à offrir une protection (immunité) contre les futures infections par la COVID-19. Les efforts de recherche dans le monde entier, y compris cette étude, cherchent à comprendre ces questions sur l'immunité.

  Veuillez continuer à suivre toutes les recommandations de la santé publique, même si vous avez des anticorps contre le virus de la COVID-19. Cela vous aidera à assurer votre propre sécurité et celle des autres.

• 5. Si j'ai des anticorps, puis-je contracter de nouveau la COVID-19?

  5. Si j'ai des anticorps, puis-je contracter de nouveau la COVID-19?

  Nous ne le savons pas encore. Les anticorps ne protègent pas toujours les gens contre de nouvelles infections. Des recherches supplémentaires sont menées dans le monde entier pour tenter de répondre à ces questions.

• 6. Pourquoi certaines personnes ont-elles un test positif de la tache de sang séché et d'autres, un test négatif de la tache de sang séché?

  6. Pourquoi certaines personnes ont-elles un test positif de la tache de sang séché et d'autres, un test négatif de la tache de sang séché?

  Certaines personnes peuvent être plus susceptibles d'être infectées que d'autres. Cela peut dépendre de la quantité de virus à laquelle elles ont été exposées. Les personnes infectées peuvent produire différentes quantités d'anticorps. Si une personne en produit peu, il se peut que le test ne puisse pas les détecter. Le fait qu'une personne infectée présente des symptômes ou non dépend de son âge, des problèmes de santé sous-jacents et d'autres facteurs que nous tentons de mieux comprendre.

• 7. Qu'est-ce que cela signifie si j'ai été testé positif au COVID-19 par le test PCR de salive mais que mon test d'anticorps est négatif ?

  7. Qu'est-ce que cela signifie si j'ai été testé positif au COVID-19 par le test PCR de salive mais que mon test d'anticorps est négatif ?

  Chaque personne produit différentes quantités d'anticorps. Si vous avez obtenu un résultat positif au test de la salive PCR, mais que le test d'anticorps est négatif, vous n'avez peut-être pas produit beaucoup d'anticorps contre l'infection. Cela ne signifie pas que le résultat de votre test de la salive PCR était erroné.

• 8. Qu'est-ce que cela signifie si mon test PCR salivaire est négatif mais que mon test d'anticorps est positif ?

  8. Qu'est-ce que cela signifie si mon test PCR salivaire est négatif mais que mon test d'anticorps est positif ?

  Le test PCR de salive peut avoir été effectué alors que le virus n'était pas présent dans votre salive, de sorte que le virus n'a pas été détecté. Un résultat positif au test d'anticorps montre que vous avez été exposé au virus ou que vous avez reçu le vaccin, et que votre organisme a fabriqué des anticorps. Il ne vous renseigne pas sur la façon dont le virus vous a affecté.9. Que dois-je faire si j'ai des questions sur les résultats de mes tests?

• 9. Que dois-je faire si j'ai des questions sur les résultats de mes tests?

  9. Que dois-je faire si j'ai des questions sur les résultats de mes tests?

  Si vous avez des questions ou des préoccupations concernant les résultats de vos tests, nous vous recommandons de vous adresser à votre prestataire de soins de santé.

• 10. Dois-je quand même me faire vacciner si j'ai obtenu un résultat positif au test d'anticorps contre la COVID-19?

  10. Dois-je quand même me faire vacciner si j'ai obtenu un résultat positif au test d'anticorps contre la COVID-19?

  Oui. Les personnes qui ont obtenu un résultat positif au test d'anticorps contre la COVID-19 doivent quand même être vaccinées. À l'heure actuelle, les experts ne savent pas combien de temps une personne peut être protégée contre une réinfection après s'être rétablie de la COVID-19.

• 11. J'ai reçu mon vaccin mais mon résultat du test d'anticorps est négatif. Qu'est-ce que cela peut signifier?

  11. J'ai reçu mon vaccin mais mon résultat du test d'anticorps est négatif. Qu'est-ce que cela peut signifier?

  Cela peut signifier que vous avez reçu votre vaccin après avoir fait votre prélèvement de gouttes de sang séché, ou que vous avez fait le prélèvement peu après avoir reçu le vaccin, ne donnant pas assez de temps à votre corps de produire une quantité suffisante d'anticorps pour être détecté par le test. Ce sont deux possibilités, parmi d'autres.

• 12. Où puis-je trouver plus de renseignements sur l'Enquête canadienne sur la santé et les anticorps contre la COVID-19 (ECSAC)?

  12. Où puis-je trouver plus de renseignements sur l'Enquête canadienne sur la santé et les anticorps contre la COVID-19 (ECSAC)?

  Pour plus de renseignements sur l'ECSAC, veuillez consulter notre site Web à Enquête canadienne sur la santé et les anticorps contre la COVID-19 (ECSAC).

• 13. Les participants peuvent-ils retirer leur consentement à la conservation de leurs biospécimens dans la Biobanque ?

  13. Les participants peuvent-ils retirer leur consentement à la conservation de leurs biospécimens dans la Biobanque ?

  Oui. Lors du prélèvement des échantillons, il est demandé aux participants s'ils consentent au stockage de leurs échantillons. À tout moment, pendant ou après la soumission des échantillons, les participants peuvent demander que leurs échantillons soient retirés du stockage et détruits en appelant le 1-888-253-1087, ou par courriel à statcan.biobankinfo-infobiobanque.statcan@statcan.gc.ca.

• 14. Quel type d'analyses sont effectuées sur les échantillons stockés à la Biobanque ?

  14. Quel type d'analyses sont effectuées sur les échantillons stockés à la Biobanque ?

  Les échantillons conservés à la Biobanque de Statistique Canada sont utilisés dans des études sur la santé. Les études sur la santé comprennent :

  • La recherche d'expositions passées à de nouveaux contaminants environnementaux.
  • Nouvelles façons de surveiller la nutrition humaine
  • La prévalence passée des maladies infectieuses, la découverte et la validation de nouveaux biomarqueurs pour diagnostiquer les maladies.
  • La recherche génétique pour évaluer l'état de santé et la susceptibilité des Canadiens aux maladies, aux infections ou aux expositions aux contaminants environnementaux.
• 15. Mes échantillons de sang séché et de salive seront-ils utilisés pour des tests génétiques?

  15. Mes échantillons de sang séché et de salive seront-ils utilisés pour des tests génétiques ?

  Oui, il est possible que votre échantillon soit utilisé pour des tests génétiques. Les tests génétiques peuvent inclure des études d'association à l'échelle du génome ou le génotypage.

  Deux projets de la Biobanque ont utilisé les informations génétiques des échantillons de la Biobanque pour établir un lien entre les données génétiques et l'état de santé. Le premier projet, réalisé par l'Agence de la santé publique du Canada, a examiné comment les différences dans le code génétique entre les Canadiens pouvaient influencer la façon dont ces derniers absorbent les nutriments. Le deuxième projet, en cours à l'Université McGill, vise à déterminer comment les différences dans le code génétique influencent les résultats de santé après une exposition à des contaminants environnementaux et à des métaux.

  En aucun cas, Statistique Canada ne divulguera votre génome au public. Statistique Canada, ou tout autre ministère fédéral qui respecte la Loi sur la protection des renseignements personnels du Canada, ne permettrait jamais que votre ADN soit utilisé de cette façon.

  Il est possible de retirer son consentement à des tests génétiques tout en conservant ses échantillons dans la Biobanque de Statistique Canada pour d'autres projets. Un participant peut retirer son consentement en tout temps en utilisant les coordonnées qui se trouvent ici : Participants de la biobanque.

• 16. Combien de temps garderez-vous mes échantillons ?

  16. Combien de temps garderez-vous mes échantillons ?

  Les échantillons sont conservés dans la Biobanque de Statistique Canada jusqu'à ce qu'ils ne soient plus scientifiquement viables. Les échantillons sont retirés lorsqu'ils sont utilisés pour un projet de recherche approuvé ou lorsqu'un participant demande que ses échantillons soient retirés et détruit.

• 17. Où puis-je obtenir plus d'informations sur la Biobanque?

  17. Où puis-je obtenir plus d'informations sur la Biobanque?

  Des renseignements supplémentaires, comme la description des études approuvées de la Biobanque, sont affichés sur la page Web de la Biobanque. Vous pouvez également accéder au site Web en entrant " Biobanque de Statistique Canada " dans votre moteur de recherche préféré.

Par : Julien-Charles Lévesque, Emploi et Développement social Canada; Marie-Pier Schinck, Emploi et Développement social Canada

Il est connu que l'anglais est la langue dominante dans le domaine du traitement du langage naturel (TLN). Cela peut représenter un défi pour les scientifiques des données du GC, qui doivent s'assurer de la qualité des données en français et du traitement équivalent des données des deux langues officielles afin d'éviter tout biais.

La Division de la science des données du Bureau de la dirigeante principale des données (BDPD) d'Emploi et Développement social Canada (EDSC) lance un projet de recherche sur l'utilisation du TLN dans les deux langues officielles. Cette initiative, financée par le Laboratoire d'innovation d'EDSC, vise à approfondir la compréhension de l'incidence de la langue (française ou anglaise) sur le comportement des techniques et des outils utilisés dans le TLN. Ceci permettra à nos scientifiques des données de prendre des décisions plus éclairées dans leurs projets de TLN.

Pourquoi est-il important d'explorer l'utilisation des deux langues officielles dans le TLN?

EDSC a été directement confronté à ce défi dans le cadre de ses projets de TLN, et certains de ses partenaires dans d'autres ministères ont indiqué qu'ils avaient également éprouvé ce problème. Bien qu'il existe de nombreuses approches possibles pour le traitement des données dans plusieurs langues, il est difficile de dire si certaines de ces approches fonctionnent mieux que d'autres pour fournir des prévisions de qualité comparable pour les deux langues officielles. Bref, étant donné que la façon dont la langue est traitée n'est jamais le seul objectif des projets, les scientifiques des données ne peuvent investir qu'une quantité limitée de temps et de ressources pour explorer cette question. Ce manque pourrait mener à des décisions qui ne sont pas optimales. Pour la langue française, il est nécessaire de mieux comprendre les répercussions des choix faits par les scientifiques des données lorsqu'ils appliquent les techniques de TLN. Cet exercice permettra d'améliorer la qualité du traitement des données en français, et de contribuer à réduire les biais liés à la langue. Cela permettra d'accroître l'équité des solutions tout en ayant une incidence sur la prestation de services aux clients.

Nouvelles recherches sur les techniques de TLN et les langues officielles

Afin de limiter l'impact de ce problème, EDSC lance un projet de recherche qui portera sur certaines questions récurrentes entourant l'application des techniques de TLN aux deux langues officielles. Cela comprend les techniques de prétraitement, de vectorisation (word embeddings) et de modélisation du texte, ainsi que les techniques pour atténuer les répercussions des ensembles de données débalancés. EDSC souhaite acquérir des connaissances transférables qui pourraient être mises à profit par son équipe et la communauté de la science des données du GC, afin d'aider à combler l'écart entre le français et l'anglais en ce qui a trait à la qualité des applications de TLN au sein du gouvernement fédéral.

Pour l'instant, seuls les problèmes de classification de texte serviront de cas d'utilisation. Il s'agit à la fois d'une tâche très courante de TLN et d'un type de problème sur lequel l'équipe a travaillé dans le cadre de nombreux projets. Cette dernière a accès à plusieurs ensembles de données réelles étiquetées provenant de projets antérieurs, ce qui lui permettra de fonder ses conclusions sur un contexte plus appliqué.

Tirer parti des ensembles de données existants

L'équipe d'EDSC utilisera des ensembles de données provenant de quatre problèmes de classification de texte qu'elle a déjà résolus. Ces problèmes varient en fonction de la longueur des documents, de la qualité du texte, de la tâche de classification (binaire ou à classes multiples), de la proportion de contenu français/anglais ainsi que de la façon dont le contenu en français a été traité. Afin de mettre les choses en perspective, chacun de ces projets passés est examiné plus en détails ci-dessous.

• Le projet T4 est un problème de classification binaire de notes rédigées par des agents des centres d'appels. L'objectif était de prédire si un T4 avait déjà été envoyé de nouveau à un client ou non.
• Le projet de surveillance des médias est un problème de classification binaire des articles de presse de NewsDesk. L'objectif était de prédire si les articles étaient pertinents pour la haute direction.
• Le projet des commentaires de relevés d'emploi est un problème de classification à classes multiples. L'objectif était de prédire quel motif de cessation d'emploi correspondait aux commentaires des employeurs sur les formulaires de relevé d'emploi.
• Le projet des ressources humaines (RH) est un projet de recherche qui a exploré la présélection des candidats dans le cadre de processus de dotation à grande échelle pour des postes de niveau d'entrée. Il s'agissait d'un problème de classification binaire dont l'objectif était de prédire l'étiquette attribuée par le personnel des RH en fonction des réponses des candidats aux questions de présélection.

Tableau 1. Aperçu des données de chaque problème et solution finale

Nom du projet	Type de problème	Taille de l'ensemble de données	Proportion du contenu en français	Longueur de la description d'entrée	Méthode utilisée
T4	Binaire	Petit (6000)	35 %	Courte	Jetons (tokens)dans les deux langues, modèle de n-grammes et khi carré + perceptron multicouche (multilayer perceptron, MLP)
Surveillance des médias	Binaire	Grand (1 M)	25 %	Longue	Français traduit en anglais, métavectorisation (de GloVe, fastText et Paragram), ensemble de classifieurs (LSTM, GRU, CNN)
Projet de commentaires relatifs au relevé d'emploi	Classes multiples	Moyen à grand (plus de 300 000)	28 %	Courte	Jetons dans les deux langues, modèle de n-grammes et khi carré + perceptron multicouche (multilayer perceptron, MLP)
RH	Binaire	Petit (5 000)	6 %	Moyenne à longue	Vectorisations de mots multilingues pré-entraînées (algorithme Bidirectional Encoder Representations from Transformers [BERT]) suivis d'ajustements

Questions de recherche clés

Ce travail permettra d'explorer les questions clés qui se posent habituellement lors de l'élaboration de solutions de TLN pour la classification. La question récurrente des ensembles de données débalancés dans les données du GC (plus de cas observés en anglais qu'en français) sera également abordée. Plus précisément, ce projet tentera de répondre aux questions suivantes :

1. Quelle est la différence entre l'utilisation d'un modèle distinct pour le français et l'anglais et l'utilisation d'un modèle unique pour les deux langues? Peut-on déduire des règles ou des lignes directrices générales lorsqu'il serait préférable d'utiliser l'une ou l'autre des approches?
2. La stratégie de traduction des données du français vers l'anglais, puis d'entraînement d'un modèle anglais unilingue est-elle valable? Quels sont les principaux facteurs à prendre en considération lorsqu'on utilise cette approche?
3. Les modèles entraînés sur une multitude de langues favorisent-ils une langue par rapport à une autre? La compréhension des documents en français équivaut-elle à la compréhension des documents en anglais avec ces méthodes?
4. Quelle est l'incidence du débalancement de la représentation linguistique dans les données? Y a-t-il un ratio minimal de données du français par rapport à l'anglais qui devrait être visé? Quelles méthodes devrait-on utiliser pour atténuer les répercussions de ce débalancement?

Partage des résultats

La majeure partie des expériences seront achevées au cours de l'été. Une présentation et un rapport seront préparés et distribués au cours de l'automne. Ce rapport détaillé documentera la recherche et l'exploration qui auront eu lieu ainsi que les conclusions. Il s'agira d'un rapport technique qui ciblera les scientifiques des données, puisque l'objectif principal de cette initiative est de leur permettre de prendre des décisions plus éclairées lorsqu'ils traitent des données en français dans le cadre de projets de TLN. De plus, un séminaire axé sur l'apprentissage automatique sera préparé pour discuter de cette initiative de recherche. Les thèmes abordés et le nombre de séances offertes seront déterminés par les conclusions de l'étude.

Créons des liens!

L'équipe espère que cette initiative de recherche apportera de la valeur aux projets bilingues de TLN à venir grâce à un traitement plus éclairé du contenu en français, offrant ainsi un produit final de meilleure qualité. Entre-temps, si vous avez aussi été confrontés à des défis similaires lors de l'utilisation du TLN dans des ensembles de données bilingues, si vous avez des commentaires, des idées ou peut-être des leçons apprises qui pourraient être intéressantes à partager, ou si vous souhaitez simplement être tenus au courant, n'hésitez pas à communiquer avec nous! L'équipe de projet vous invite à discuter avec la communauté de la science des données du GC en rejoignant la conversation dans le Réseau des utilisateurs et praticiens de l'intelligence artificielle!

Scientifiques des données

Marie-Pier Schinck (Scientifique des données), Julien-Charles Lévesque (Scientifique des données)