 |
| Data Science & Plateformes techniques |
Un constat réalisé lors de différents échanges : La Data Science est aujourd’hui souvent perçue comme associée à des plateformes techniques puissantes enrichies de cartes graphiques (GPU) et nécessitant le plus souvent, une hybridation dans le Cloud pour bénéficier de la puissance nécessaire aux phases d’apprentissage.
Mais est-ce la seule stratégie pour faire bénéficier son organisation des apports de l’apprentissage profond (DeepLearning) ?
Il n'existe à ce jour aucune réponse définitive à cette question ! Cependant, j’étayerai le raisonnement en gardant à l’esprit les algorithmes de type « réseaux de neurones à convolution » basés sur des filtres et la recherche d’un motif dans une image (Yann Le Cun – 1990). En effet, ceux-ci sont utilisés dans l’assurance pour analyser par exemple, les croquis d’accident des constats européens d’accident, les photographies d’expertise des dégâts sur les automobiles, …
Classiquement le développement d’un produit répondant à ce besoin comportera au moins les quatre étapes suivantes :
- La première étape consistera à collecter des données (ici les images) : plusieurs centaines par catégorie seront sûrement nécessaire pour éviter le sur-apprentissage et à les transférer sur votre infrastructure de travail.
- La deuxième étape peu gratifiante mais au combien nécessaire, sera de les annoter pour alimenter l’algorithme. En effet ces étapes obligatoires de préparation et de mise en qualité des données restent toujours très consommatrices en temps et en énergie humaine.
- La troisième étape aura pour nature l’entrainement du modèle pour minimiser les erreurs de classification. Cette phase nécessite souvent une puissance de traitement importante et l’utilisation de cartes graphiques contenant des milliers d’unités de calcul : elles permettent un gain indéniable en temps. En outre, il est important dans cette phase d’avoir dans l’équipe des experts en Data Science.
- La dernière étape sera d’inscrire ce modèle sur le sentier technologique de mise en production (API, Batch, Techno, …). Également, il faudra construire un plan qualité permettant un réentrainement automatique du modèle ou a minima une procédure permettant de s’assurer qu’il ne dérive pas…
Des étapes d’une durée difficilement compressible et qui de surcroit nécessitent une bonne dose d’expertise. Loin de moi l’idée de nier la nécessité d’avoir des talents dans ce domaine ;-). Cependant, une autre stratégie peut être mise en œuvre pour contraindre le temps nécessaire aux étapes une à quatre : le « Transfert Learning » et ainsi contribuer à la diminution du temps de mise en marché (le graal !).
L’idée est de capitaliser sur les capacités déjà acquises d’un réseau de
neurones pour les appliquer à un cas d’usage voisin en s’appuyant sur
des bibliothèques d’algorithmes entrainés et disponibles en Open Source.
D’ailleurs GitHub regorge de modèles répondant à différentes
problématiques. Toutefois, pour affiner les résultats (Fine Tuning), il
peut être intéressant d’ajouter une phase de réentrainement dédié au
nouveau cas d’usage. Notons que cette approche nécessite beaucoup moins
de données (donc un temps d’annotation plus faible) et beaucoup moins
d’expertise (un ajout de filtres) ainsi qu’une puissance de calcul
nettement moindre (utilisation d’infrastructures classiques).
Cloud ou pas Cloud ?
La réponse doit faire sens dans le contexte data de chaque entreprise en fonction des contraintes et des enjeux. Cette question présente peu de sens pour des produits construits via « transfert learning »: toutes les infrastructures conviennent. Cependant, cette question reste entière pour les autres techniques d’apprentissage. Dans tous les cas, ce choix doit être fait pour répondre à des points de souffrance : gain en agilité des projets, scalabilité des infrastructures, budgets des projets orientés OPEX, … profiter des offres packagées proposées par OVH, Google, Amazon, …
Toutefois, il faut se garder d’« hybrider » ou « cloudifier » les architectures Data uniquement dans une approche purement technologique. Ces environnements amènent aussi des contraintes : une duplication des données dans un nouveau container (silo ?), une gouvernance des données à faire évoluer, une gestion de l’interopérabilité entre les environnements ainsi que la réversibilité, une structure de coûts différente, une nouvelle stratégie de mise en marché, …
Le « Transfert Learning » un élément clé pour démocratiser l’usage du Deep Learning ?
En somme, les freins aux déploiements massifs de technologies basées sur le Deep Learning proviennent du temps passé à préparer les données (nettoyage, annotation, …) et à calibrer les algorithmes. Aujourd’hui la richesse des modèles pré-entrainés et librement disponibles (Open Source) permettent de répondre avec des plateformes technologiques courantes à de nombreuses préoccupations des organisations : analyse de verbatims clients, vérification de documents, analyses de carte, …
Pour conclure, J’ai la conviction que le « Transfert Learning » participera à la diffusion de solutions construites à partir d’apprentissage machine. Toutefois, il faudra prendre garde que cette technique, utilisée sans les éléments de contexte de l’apprentissage, ne conduise pas à une propagation de biais non volontaires …
Et là c’est une question d’éthique !
Liens :
