Les leçons d’apprentissage automatique que j’ai apprises ce mois-ci

parfois vingt-neuf. Nous sommes en février : un mois court.

Environ quatre semaines standards. Une vingtaine de jours ouvrables. À grande échelle, peu de progrès se produisent au cours de ces 4 x 5 jours. Et pourtant, comme toujours, beaucoup de choses sont accomplies au jour le jour. Quelques expériences sont en cours. Quelques idées sont rejetées. Quelques discussions font avancer les choses. Quelques modifications de code s’avèrent plus importantes que prévu.

En repensant au mois dernier, j’ai trouvé trois leçons qui m’ont marqué dans le monde de la recherche et de l’ingénierie ML :

• Les échanges avec les autres sont importants,
• la documentation est souvent sous-estimée jusqu’à ce qu’il soit trop tard,
• et MLOps n’a de sens que s’il s’adapte réellement à l’environnement dans lequel il est censé être utilisé.

---

1. Échanges avec les autres

Si vous lisez régulièrement des articles sur le ML, vous connaissez le modèle : dans les citations, seul le nom du premier auteur est généralement affiché. Les autres noms n’apparaissent que dans la section références. Cela signifie-t-il que le premier auteur a tout fait tout seul ?

Rarement. Uniquement dans le cas particulier où un seul auteur a rédigé uniquement l’article.

La plupart des recherches vivent de l’échange. Il vit de discussions avec des co-auteurs, de commentaires de collègues, de questions qui obligent à affiner sa réflexion et de disciplines adjacentes apportant des idées que votre propre domaine n’aurait pas produit à lui seul. Une bonne recherche donne souvent l’impression d’entrer dans le territoire d’autrui et d’apprendre juste assez de leur langage pour rapporter quelque chose d’utile.

Mais cela n’est pas uniquement vrai pour les articles universitaires. Cela est également vrai pour le travail d’ingénierie quotidien.

Un bref échange avec un collègue peut vous éviter des heures de errance. Une conversation de cinq minutes devant la machine à café peut vous donner la pièce manquante qui fait cliquer votre configuration. Même les discussions informelles comptent. Toutes les discussions utiles ne démarrent pas lors d’une réunion programmée avec un diaporama raffiné. Parfois, cela commence par « au fait, j’ai remarqué quelque chose d’étrange dans les journaux ».

Ce mois-ci me l’a encore rappelé. Quelques petits échanges ont clarifié les choses beaucoup plus rapidement qu’une réflexion solitaire ne l’aurait fait. Rien de dramatique, rien de digne d’un discours d’ouverture – juste l’avantage normal et tranquille de parler à d’autres personnes qui pensent à des choses similaires.

2.Documents

Avez-vous déjà apporté des modifications à votre code ?

Bien sûr que oui.

Et pourrais-tu encore te souvenir du lendemain pourquoi tu as fait ces changements ? J’espère que oui – ce n’est qu’un jour, après tout. Mais qu’en est-il une semaine plus tard ? Un mois plus tard ? Six mois plus tard ?

C’est là que les choses deviennent moins évidentes.

La plupart des modifications apportées à une base de code sont petites et bénignes. Toutes les petites corrections de bugs ne méritent pas une longue explication. Si vous renommez une variable, corrigez une faute de frappe ou corrigez un problème de journalisation inoffensif, cela ne nécessite généralement pas de documentation spéciale. Il en va souvent de même pour les corrections de bogues qui ne modifient aucune conclusion pertinente des résultats antérieurs.

Mais certains changements sont différents.

Certains changements modifient les hypothèses. Certains modifient la façon dont les données sont prétraitées. Certains affectent les caractéristiques de la formation, la logique d’évaluation, voire même la signification des sorties. Ces changements méritent d’être notés, car ce sont exactement ceux que vous aurez oubliés lorsque vous reviendrez sur le projet plus tard.

Ce mois-ci, on m’a encore rappelé que la documentation n’est pas principalement destinée à un futur collaborateur abstrait. C’est pour votre futur moi. Aujourd’hui, alors que vous êtes plongé dans le code, tout semble évident. Dans trois mois, ce ne sera plus le cas. Ensuite, vous regarderez une ligne, ou une configuration, ou une mystérieuse transformation de données, et vous vous demanderez : « Pourquoi diable ai-je procédé de cette façon ?

C’est une question facilement évitable.

3. MLOps mis en pratique

L’objectif de la plupart des recherches en ML est, sous une forme ou une autre, de produire des modèles entraînés.

Mais je parierais que seule une petite minorité de ces modèles est réellement utilisée.

De nombreux modèles restent là où ils sont nés : dans des cahiers, sur des serveurs de recherche, dans des présentations internes ou dans des articles. Pour aller au-delà de cela et mettre un modèle en œuvre de manière productive, il vous faut plus que le modèle lui-même. Vous avez besoin d’infrastructures, de processus, de surveillance, de reproductibilité, de stratégies de déploiement, en d’autres termes, d’outils et de principes MLOps.

Si vous lisez les offres d’emploi dans ce sens, MLOps apparaît souvent étroitement lié aux fournisseurs de cloud : AWS, GCP, Azure, pipelines cloud natifs, services gérés, environnements de déploiement distribués. Et oui, ces outils sont importants. Ils sont importants et, dans de nombreux contextes, ils constituent exactement le bon choix.

Mais il convient de se poser une question simple : l’environnement cible est-il réellement un environnement cloud ?

Effectuez un contrôle qualité automatisé dans un environnement industriel. Supposons qu’un modèle soit utilisé directement en production, à proximité des machines qui créent le produit. Pensons-nous vraiment que toutes les données pertinentes sont simplement transmises depuis l’entreprise vers un cloud ? Surtout si ces données reflètent les processus fondamentaux de l’entreprise et font donc partie de son avantage concurrentiel ? Je doute que de nombreuses entreprises soient tout à fait à l’aise pour exposer de cette manière des environnements critiques pour la production.

C’est là qu’une vision plus fondée du MLOps devient importante.

MLOps est utile, oui. Mais il ne s’agit pas d’un ensemble d’outils spécifiques, mais plutôt d’un ensemble de méthodes permettant de reproduire un outil dans des conditions changeantes. Et il doit s’adapter à l’environnement dans lequel il est destiné à être utilisé – et non l’inverse. L’objectif n’est pas d’imposer tous les problèmes de déploiement dans le moule des outils à la mode. L’objectif est de rendre les modèles utiles sous des contraintes réelles, en créant les outils nécessaires au problème posé.

Parfois, cela signifie des pipelines cloud. Parfois, cela signifie un déploiement sur site. Parfois, cela signifie des environnements restreints avec une connectivité limitée, un contrôle d’accès strict ou des contraintes matérielles à la périphérie. Dans tous ces cas, les principes restent similaires : versioning, reproductibilité, monitoring, déploiement sécurisé, robustesse de fonctionnement. Mais la mise en œuvre peut être très différente.

Pensée finale

Février a été court, mais pas vide. Comme tous les autres mois de l’année, il y a de nombreuses leçons à tirer :

• les progrès en ML dépendent souvent de l’échange avec les autres, et pas seulement d’une réflexion solitaire,
• la documentation compte le plus précisément lorsque vous pensez que vous n’en aurez pas besoin,
• et MLOps ne devient utile que lorsqu’il est adapté à l’environnement réel.

Je parie que le mois prochain, il y aura une autre série de ces leçons. Pas nécessairement des leçons tape-à-l’œil, mais des leçons discrètes du type « oh, oui, c’est probablement une bonne façon » qui dictent les actions quotidiennes.