Considérations d’ordre technique
Cette partie décrit ce qu’il faut prendre en compte quand on utilise ou adapte la Solution type.
Déploiement
La Solution type est déployée sur un serveur d’inférence TensorRT, mais le modèle TensorFlow pourrait être employé directement dans un environnement de production sans exportation du modèle ni exploitation d’un tel serveur. TensorRT est généralement plus efficace avec une unité de traitement graphique (GPU) et établit des prévisions plus vite que les solutions de rechange.
Dans la Solution type, l’application cliente et le serveur d’inférence se trouvent sur le même hôte, pour plus de simplicité. Cependant, il est plus courant d’utiliser des hôtes différents, ce qui nécessitera l’ouverture des ports correspondants afin qu’ils communiquent entre eux.
Solutions de rechange
Plutôt que TensorFlow, on pourrait bâtir et former le modèle avec PyTorch, autre cadre populaire d’apprentissage machine reposant sur Python et compatible avec le serveur d’inférence TensorRT. Vous trouverez sur Internet de nombreuses analyses comparant l’un et l’autre. En voici quelques-unes : Awni Hannin: PyTorch or TensorFlow?, TensorFlow or PyTorch: The Force is Strong with Which One?, PyTorch vs. TensorFlow — Spotting the Difference et The Battle: TensorFlow vs Pytorch.
Architecture des données
La Solution type repose sur un jeu de données constitué, dans ce cas, d’un simple fichier texte. Plusieurs points doivent être pris en considération eu égard aux données, aux éléments du code qui en dépendent, à la façon de l’élargir et aux pratiques exemplaires.
Les deux composants principaux qui exploitent directement le jeu de données sont le pipeline qui met dernières en mémoire pour former le modèle et l’application cliente qui formule les prévisions (titres de films). Ces composants devront être modifiés si on change l’architecture des données. Par exemple, on pourrait stocker les informations dans une base de données qui, soit serait versée dans un fichier avant que le pipeline actuel le traite, soit à laquelle le code puiserait directement. Le code de l’application cliente, par exemple, pourrait verser les données d’un fichier ou d’une base de données dans un tableau de hachage ou consulter la base de données à chaque demande.
Pour enrichir les données avec de nouveaux utilisateurs ou longs métrage, on devra former le modèle à nouveau. Dans un environnement de production, la solution prévoirait un recyclage périodique du modèle et ne proposerait de recommandations personnalisées qu’après fois que l’utilisateur aura recouru assez souvent au système pour que celui-ci ait accumulé les données requises. Habituellement, les projets de ce genre proposent des recommandations générales sur des thèmes populaires avant de passer à des recommandations plus personnalisées.
Enfin, puisque les données pourraient incorporer des renseignements personnels sur l’utilisateur, le développeur qui crée une solution similaire devra respecter les pratiques en usage sur la gestion des données sensibles. Le module de formation, par exemple, n’a besoin que de l’identifiant, pas du nom de l’utilisateur ni d’autres renseignements. Cependant, pour formuler les prévisions, l’application devra pouvoir déterminer de quel utilisateur il s’agit (ouverture d’une séance, par exemple), lui attribuer une identité et en faire de même avec les longs métrages. On appliquera donc les pratiques reconnues par l’industrie aux composants qui recueillent les données des utilisateurs, les emmagasinent, s’en servent pour former le modèle et puisent dans les données pour convertir l’identifiant en texte ordinaire.
Sécurité
Après déploiement, il existe un léger risque que des gens mal intentionnés accèdent à l’environnement de la Solution type pour la modifier et organiser une cyberattaque (par déni de service notamment). On atténuera ce risque en épousant les pratiques exemplaires de l’ATIR concernant le déploiement de scripts, c’est-à-dire :
- établir des règles qui interdisent l’accès à tous les ports, sauf le port 22 du SSH de l’instance qui a été déployée, dans le pare-feu;
- contrôler les accès afin que seuls les participants de l’ATIR puissent déployer et utiliser une instance de la Solution type après authentification.
Pour diminuer encore plus les risques, on suivra les recommandations que voici :
- utiliser les contrôles de sécurité qui ont été déployés sans les modifier;
- une fois qu’on en a fini avec la solution de référence, la supprimer comme on l’a expliqué plus haut (section « clôture »).
Employée de façon autonome, la Solution type ne consomme pas directement les ressources du réseau ni des installations de stockage en cours d’exécution. Aucune procédure n’est donc nécessaire pour réguler ces ressources.
Réseau
Les clients peuvent consulter le serveur d’inférence au moyen des protocoles HTTP ou gRPC (Google Remote Procedure Call). Il n’y a aucune autre considération spécifique au réseau.
Mise à l’échelle
La Solution type utilise un modèle passif. En d’autres termes, le même modèle peut être déployé sur de nombreux serveurs d’inférence, ce qui permet d’implanter une architecture standard très évolutive qui acceptera de multiples demandes parallèles et un équilibreur qui répartira la charge entre les serveurs.
Disponibilité
Le serveur d’inférence TensorRT incorpore une API qui veille à ce que le serveur puisse répondre aux demandes d’inférence. Il est donc possible d’ajouter le serveur comme un hôte ordinaire dans une architecture axée sur une forte disponibilité et de pointer l’équilibreur sur l’API du serveur pour qu’il bloque les demandes, change d’hôte ou en démarre un nouveau quand l’intensité des activités sur le serveur le justifie.
Interface utilisateur (IU)
L’interface de la Solution type se résume à une ligne de commande qui met en relief le programme en arrière-plan. L’IU variera en fonction de l’usage qu’on en fait, mais cela déborde du propos de notre exemple.
API
L’interface du protocole d’application est en code Python ordinaire. Elle est structurée de façon modulaire et est accompagnée de commentaires explicites. Le développeur pourra s’en inspirer pour créer une solution sur mesure.
Coût
La solution n’exige qu’une instance de GPU dans l’ATIR, ce qui équivaut à environ 100 $ par mois dans un nuage public.
Licence d’exploitation
Toutes les bibliothèques utilisées par la Solution type sont de source ouverte. Il en va autant pour le code du Recommandeur de films. Le jeu de données MovieLens peut être utilisé à des fins non lucratives sous certaines conditions. Voir les informations concernant les licences d’exploitation ci-dessous. Vous devrez vous conformer aux dispositions des différentes licences avant d’exploiter, de modifier, d’élargir ou de diffuser l’un ou l’autre composant de la Solution type.
CODE SOURCE
On trouvera le code source de la Solution type ici. Veuillez lire le fichier README.md pour savoir comment le cloner et utiliser le dépôt de données.
Glossaire
Expression |
Description |
API |
Interface de protocole d’application |
Apprentissage profond |
Méthode d’apprentissage machine faisant appel aux réseaux neuronaux |
ATIR |
Accélérateur technologique pour la recherche et l’innovation. Se rapporte au projet pilote lancé à l’automne 2019. |
CUDA |
Compute Unified Device Architecture. Modèle de programmation et plateforme de calcul en parallèle de NVIDIA |
Filtrage collaboratif |
Technique employée par les systèmes de recommandation pour prévoir automatiquement ce qui pourrait intéresser l’utilisateur après avoir recueilli des données sur les goûts ou les préférences d’autres utilisateurs (collaborateurs). |
GPU |
Unité de traitement graphique. Dispositif autorisant un traitement ultra performant des données en parallèle |
IU
|
Interface utilisateur |
Système de recommandation ou recommandeur |
Modèle d’apprentissage machine qui prévoit la « note » qu’un utilisateur attribuera à un article ou ses « préférences ». Il suggère des articles pertinents à l’utilisateur. |