Ask HN : Que font les ingénieurs en machine learning pendant leurs heures de travail ?

xguru · 2024-06-10T10:26:01+09:00

Résumé des réponses apportées à la question schmookeeg Ce qu’il préfère le plus dans son poste actuel d’ingénieur en machine learning, c’est de collaborer avec des personnes sans bagage technique Même des gens qui n’arrivent pas à ouvrir MS Outlook plus de 3 fois sur 5 ont une profondeur et une clairvoyance étonnantes dans leur domaine d’expertise C’est très humblement instructif Les personnes sans bagage technique le voient comme un magicien, et lui les voit comme des prêtres vaudous Quand on entraîne ce qu’on aime et qu’on fait des prédictions, c’est très gratifiant pour les deux côtés La majorité de la modélisation concerne le secteur médical Il extrait des insights d’un immense data lake de facturation, ordonnances, comptes rendus médicaux, signes vitaux, imagerie diagnostique, etc. Le fait d’avoir un accès aussi facile à ces informations est énorme aussi (HIPAA mis à part) Réalité du temps passé Environ 3 heures de réunions par semaine Environ 3 heures pour préparer le travail, résoudre des problèmes d’ETL et effectuer des requêtes ponctuelles pour le business Le reste du temps consiste à explorer les données pour trouver un léger avantage dans la prédiction de revenus de plusieurs millions de dollars C’est un peu comme chercher Charlie avec des maths Sauf que la scène de Charlie fait environ 50 To :D burnedout_dc4e3 Il travaille dans le machine learning depuis le milieu des années 2000 La moitié de son temps est consacrée à nettoyer les données pour entraîner et utiliser les modèles, autrement dit à « maintenir les pipelines de données en fonctionnement » L’autre moitié est consacrée au support technique pour des « scientifiques IA » qui n’ont pratiquement aucune compétence en code Ils passent leur temps à copier-coller du contenu dans divers services de chatbot Son travail principal consiste à leur expliquer comment installer des packages Python et utiliser Git Ils n’ont aucun plan sur la façon dont leur travail s’appliquera aux projets en cours Mais ils affirment que les modèles Transformer vont résoudre tous les problèmes de traitement de données Il envisage de quitter son poste sans en reprendre un autre tant que ce cycle de hype ne sera pas terminé tambourineman88 Une réalité à l’opposé de ce qu’il imaginait en étudiant le machine learning 95 % du travail consiste à nettoyer les données, fusionner des datasets et faire du feature engineering L’ajustement et le test des modèles ne représentent que 5 % Réponse n°1 à ce message Ça a toujours été comme ça depuis le début, et ça continuera, amen Points importants au niveau staff/responsable Il est important de maintenir « l’impédance des données » entre les fonctionnalités produit qui reposent sur des modèles d’inférence et la capture des données Cela vise à éviter que l’instrumentation et la granularité des données qui alimentent les stockages de données et les corpus d’entraînement ne se cassent quand le produit ou la fonctionnalité évolue Points importants dans les problèmes de reinforcement learning (RL) Il est important de vérifier que les bonnes variables sont capturées pour les tuples espace d’état / espace d’action Ensuite, il faut trouver comment ajuster l’interface ou le modèle d’environnement pour obtenir le feedback de récompense davedx Exécute pip install pytorch L’environnement se casse Passe 4 heures à réparer l’environnement Python Exécute pip install Pillow Reçoit une erreur disant que cela ne correspond pas à l’architecture CPU de son MacBook Passe encore 4 heures à supprimer tout ce qui est lié à Python puis à tout réinstaller depuis zéro S’apprêtait à exécuter pip install ..., mais c’est déjà l’heure de partir ! Xenoamorphous C’est un développeur logiciel généraliste qui a dû faire du ML par nécessité Il se demande comment les « vrais » spécialistes ML gèrent l’écart entre les résultats probabilistes / par descente de gradient et les attentes des gens Dans le développement logiciel classique, soit ça marche soit ça ne marche pas, et si ça ne marche pas on peut expliquer pourquoi et, espérons-le, corriger Mais en ML, on lui pose des questions comme « Pourquoi ce classifieur de texte n’a-t-il pas correctement classé ce texte ? » Et il ne peut répondre que des choses comme « il lui manquait 0,004 point pour atteindre le seuil » ou « le choix ou l’ordre des mots n’a pas permis d’y arriver » Cela semble laisser tout le monde insatisfait angarg12 Son intitulé de poste est ingénieur ML, mais dans les faits son travail est presque du pur software engineering Son travail principal consiste à construire des systèmes qui prennent en charge les systèmes ML en production Comme d’autres l’ont mentionné, cela inclut surtout la transformation des données, l’entraînement des modèles, le model serving, etc. Son travail comprend aussi la création d’outils ou la modification de systèmes existants pour permettre aux scientifiques de faire leur travail Mais vu de l’extérieur, son entreprise semble être un cas atypique Dans le secteur, les attentes vis-à-vis des ingénieurs ML semblent davantage correspondre à ce que font les data scientists / applied scientists (par exemple construire et tester des modèles) Cela crée beaucoup d’ambiguïté quant aux attentes associées à chaque rôle dans chaque entreprise runban Un agent d’entretien très bien payé Avec des données sales, on n’obtient pas de bons résultats Au passage, Perl est bien meilleur que Python pour ce travail Un dépanneur de cartes mères très bien payé Même avec du watercooling, les H100 chauffent vraiment beaucoup Parce qu’il n’y a pas de personne dédiée au hardware Et comme tout le monde, il se bat contre des dépendances tierces capricieuses primaprashant Il travaille comme MLE depuis 5 ans et, comme mentionné dans d’autres commentaires, l’essentiel du travail ressemble à du SWE Selon l’étape du projet, le travail quotidien varie, mais relève généralement de l’un des points suivants : collaboration avec les parties prenantes et les TPM, et élaboration d’hypothèses via l’analyse de données pour résoudre des problèmes business prioritaires formulation d’un problème business sous forme de problème ML, et création de métriques adaptées au modèle ML et au problème business construction de PoC et de prototypes pour valider la faisabilité technique de nouvelles fonctionnalités et idées rédaction de documents de conception pour l’architecture et les décisions techniques collaboration avec les équipes plateforme pour mettre en place et maintenir les pipelines de données selon les besoins des nouveaux projets ML et des projets existants construction, déploiement et maintenance de microservices ML pour l’inférence exécution d’A/B tests et rédaction de documents de conception pour l’analyse post-test mise en place de pipelines pour le réentraînement des modèles ML jackspawn Il consacre plus de 50 % de son temps au backend engineering Parce que le ML est utilisé au sein d’une API plus large Il est responsable de l’expérience end-to-end de cette API Donc il fait tout ce qui apporte le meilleur rapport valeur/temps Et cela n’a souvent rien à voir avec les modèles ML mardifoufs Il travaille sur l’optimisation du code d’inférence et sur la « mise en produit » de modèles entraînés Actuellement, il travaille sur de l’entraînement et de l’inférence en local, car il est dans un secteur où les services cloud ne sont pas encore couramment utilisés Comme ce n’est pas du LLM, il y a moins d’outils prêts à l’emploi, ce qui rend le travail intéressant Il faut construire beaucoup de choses soi-même Son travail va de l’évaluation de la qualité des données (la partie locale est complexe) jusqu’à l’utilisation directe de CUDA Parce qu’il existe des bibliothèques de traitement du signal déjà construites sur CUDA dont il peut tirer parti Cela inclut parfois aussi la création d’outils internes pour l’équipe (équipe mixte chercheurs/MLE) Comme c’est un domaine très niche, ils doivent construire eux-mêmes des outils pour visualiser les données et l’inférence Il dispose d’une liberté totale sur les outils et la conception logicielle interne, ce qui lui a permis d’avoir beaucoup d’influence dans l’organisation L’un des outils bricolés sur le vif va maintenant être intégré au produit phare hirako2000 Ce n’est pas sa mission principale, mais il passe l’essentiel de son temps à « raccorder des morceaux » ajuster de l’open source existant trouver comment optimiser les ressources réentraîner des modèles sur d’autres datasets essayer d’exécuter du code Python mal écrit ajouter les fichiers de requirements manquants nettoyer les données Il réfléchit à ce qui pourrait réellement être utilement résolu par le ML et qui ne l’a pas déjà été il y a des années Il vérifie les prix actuels des GPU et calcule s’il vaut mieux en acheter plutôt que louer des créneaux coûteux chez un hébergeur Il lit des articles de recherche jusqu’à en avoir mal à la tête en prenant le temps de lire le résumé et de survoler quelques schémas au milieu tenache Il a étudié le machine learning et a été recruté à l’origine pour ce rôle, mais l’entreprise a changé de direction et il travaille désormais sur des LLM Il passe l’essentiel de son temps sur des tâches comme : comprendre comment fonctionnent différents LLM trouver les meilleurs paramètres comprendre comment faire du RAG (Retrieval-Augmented Generation) comprendre comment les intégrer avec d’autres bots trybackprop Sur une semaine donnée, il fait généralement le type de travail suivant : 15 % : réunions de discussion technique ou 1:1 En général, pour discuter d’idées autour des modèles, de plans ou du support aux produits ML 40 % : développement ML Aux premières étapes d’un projet, il cherche à comprendre les exigences produit Il discute avec l’équipe des modèles ML ou des algorithmes qui pourraient aider à atteindre les objectifs produit / business Il récupère des datasets existants auprès d’analystes et de data scientists Il construit des pipelines à partir de ces datasets pour créer les jeux de données d’entraînement et de validation Pendant qu’il attend que ces jeux de données soient remplis (cela peut prendre jusqu’à 2 semaines), il travaille en parallèle sur d’autres projets plus ou moins avancés Il travaille aussi sur de nouveaux modèles (écrits en PyTorch), les teste sur de petits volumes de données pour évaluer les performances offline et juger s’ils se comportent comme prévu Il effectue quelques tests manuels avec le modèle pour remplir des informations produit et vérifier sa solidité (sans expérimentation à grande échelle, il faut s’appuyer sur son intuition et celle de l’équipe) Une fois les jeux de données d’entraînement/validation prêts, il entraîne les modèles sur de gros volumes de données, examine les résultats offline et, s’il y a des problèmes, ajuste le modèle ou change l’architecture Si les résultats offline sont bons ou semblent bons, il déploie le modèle en production pour expérimentation En parallèle, il peut modifier le code produit / infrastructure pour tester le nouveau modèle qu’il a construit Il lance les expériences et augmente lentement le trafic jusqu’à une allocation de 1 à 5 %, puis les laisse tourner plusieurs semaines ou un mois Pendant ce temps, il observe les résultats et surveille tous les pipelines concernés pour s’assurer que le modèle est correctement entraîné et que les résultats de l’expérience ne sont pas faussés par des facteurs d’infrastructure, des bugs ou des éléments produit imprévus Si les résultats semblent conformes aux attentes et cohérents avec l’hypothèse initiale, il discute avec l’équipe d’un lancement ; si la décision est prise, il lance ! (Remarque : le développement de modèle inclut la rédaction de features, la préparation des datasets, l’analyse, la création du modèle ML lui-même et l’implémentation de modifications dans le code produit / infrastructure) 20 % : maintenance Ce n’est pas parce qu’il développe de nouveaux modèles qu’il ignore les modèles existants Il les vérifie chaque jour pour s’assurer que les performances ne se dégradent pas ou ne changent pas de manière inattendue Il corrige aussi les pipelines et les rend plus efficaces 15 % : lecture de papiers de recherche et montée en compétences Le monde de l’IA / ML évolue vite, donc il lit en continu de nouveaux papiers et teste chez lui de nouvelles techniques pour rester à jour Comme cela lui plaît, il ne le vit pas comme un fardeau Il ne considère pas cela comme une corvée nécessaire pour rester à niveau 10 % : recherche interne Il utilise ce temps pour en apprendre davantage sur les autres produits de l’équipe ou de l’entreprise, et voir comment son équipe pourrait aider ou quelles techniques / approches elle pourrait leur emprunter Il l’utilise aussi pour prendre du recul sur le travail des 6 à 12 derniers mois et noter les enseignements tirés

(news.ycombinator.com)

36 points par xguru 2024-06-10 | 4 commentaires | Partager sur WhatsApp

Résumé des réponses apportées à la question

schmookeeg

Ce qu’il préfère le plus dans son poste actuel d’ingénieur en machine learning, c’est de collaborer avec des personnes sans bagage technique
- Même des gens qui n’arrivent pas à ouvrir MS Outlook plus de 3 fois sur 5 ont une profondeur et une clairvoyance étonnantes dans leur domaine d’expertise
- C’est très humblement instructif
Les personnes sans bagage technique le voient comme un magicien, et lui les voit comme des prêtres vaudous
- Quand on entraîne ce qu’on aime et qu’on fait des prédictions, c’est très gratifiant pour les deux côtés
La majorité de la modélisation concerne le secteur médical
- Il extrait des insights d’un immense data lake de facturation, ordonnances, comptes rendus médicaux, signes vitaux, imagerie diagnostique, etc.
- Le fait d’avoir un accès aussi facile à ces informations est énorme aussi (HIPAA mis à part)
Réalité du temps passé
- Environ 3 heures de réunions par semaine
- Environ 3 heures pour préparer le travail, résoudre des problèmes d’ETL et effectuer des requêtes ponctuelles pour le business
- Le reste du temps consiste à explorer les données pour trouver un léger avantage dans la prédiction de revenus de plusieurs millions de dollars
  - C’est un peu comme chercher Charlie avec des maths
  - Sauf que la scène de Charlie fait environ 50 To :D

burnedout_dc4e3

Il travaille dans le machine learning depuis le milieu des années 2000
La moitié de son temps est consacrée à nettoyer les données pour entraîner et utiliser les modèles, autrement dit à « maintenir les pipelines de données en fonctionnement »
L’autre moitié est consacrée au support technique pour des « scientifiques IA » qui n’ont pratiquement aucune compétence en code
- Ils passent leur temps à copier-coller du contenu dans divers services de chatbot
  - Son travail principal consiste à leur expliquer comment installer des packages Python et utiliser Git
- Ils n’ont aucun plan sur la façon dont leur travail s’appliquera aux projets en cours
  - Mais ils affirment que les modèles Transformer vont résoudre tous les problèmes de traitement de données
Il envisage de quitter son poste sans en reprendre un autre tant que ce cycle de hype ne sera pas terminé

tambourineman88

Une réalité à l’opposé de ce qu’il imaginait en étudiant le machine learning
- 95 % du travail consiste à nettoyer les données, fusionner des datasets et faire du feature engineering
- L’ajustement et le test des modèles ne représentent que 5 %
Réponse n°1 à ce message
- Ça a toujours été comme ça depuis le début, et ça continuera, amen
- Points importants au niveau staff/responsable
  - Il est important de maintenir « l’impédance des données » entre les fonctionnalités produit qui reposent sur des modèles d’inférence et la capture des données
  - Cela vise à éviter que l’instrumentation et la granularité des données qui alimentent les stockages de données et les corpus d’entraînement ne se cassent quand le produit ou la fonctionnalité évolue
- Points importants dans les problèmes de reinforcement learning (RL)
  - Il est important de vérifier que les bonnes variables sont capturées pour les tuples espace d’état / espace d’action
  - Ensuite, il faut trouver comment ajuster l’interface ou le modèle d’environnement pour obtenir le feedback de récompense

davedx

Exécute pip install pytorch
L’environnement se casse
Passe 4 heures à réparer l’environnement Python
Exécute pip install Pillow
Reçoit une erreur disant que cela ne correspond pas à l’architecture CPU de son MacBook
Passe encore 4 heures à supprimer tout ce qui est lié à Python puis à tout réinstaller depuis zéro
S’apprêtait à exécuter pip install ..., mais c’est déjà l’heure de partir !

Xenoamorphous

C’est un développeur logiciel généraliste qui a dû faire du ML par nécessité
Il se demande comment les « vrais » spécialistes ML gèrent l’écart entre les résultats probabilistes / par descente de gradient et les attentes des gens
Dans le développement logiciel classique, soit ça marche soit ça ne marche pas, et si ça ne marche pas on peut expliquer pourquoi et, espérons-le, corriger
Mais en ML, on lui pose des questions comme « Pourquoi ce classifieur de texte n’a-t-il pas correctement classé ce texte ? »
- Et il ne peut répondre que des choses comme « il lui manquait 0,004 point pour atteindre le seuil » ou « le choix ou l’ordre des mots n’a pas permis d’y arriver »
- Cela semble laisser tout le monde insatisfait

angarg12

Son intitulé de poste est ingénieur ML, mais dans les faits son travail est presque du pur software engineering
Son travail principal consiste à construire des systèmes qui prennent en charge les systèmes ML en production
- Comme d’autres l’ont mentionné, cela inclut surtout la transformation des données, l’entraînement des modèles, le model serving, etc.
Son travail comprend aussi la création d’outils ou la modification de systèmes existants pour permettre aux scientifiques de faire leur travail
Mais vu de l’extérieur, son entreprise semble être un cas atypique
Dans le secteur, les attentes vis-à-vis des ingénieurs ML semblent davantage correspondre à ce que font les data scientists / applied scientists (par exemple construire et tester des modèles)
- Cela crée beaucoup d’ambiguïté quant aux attentes associées à chaque rôle dans chaque entreprise

runban

Un agent d’entretien très bien payé
- Avec des données sales, on n’obtient pas de bons résultats
- Au passage, Perl est bien meilleur que Python pour ce travail
Un dépanneur de cartes mères très bien payé
- Même avec du watercooling, les H100 chauffent vraiment beaucoup
- Parce qu’il n’y a pas de personne dédiée au hardware
Et comme tout le monde, il se bat contre des dépendances tierces capricieuses

primaprashant

Il travaille comme MLE depuis 5 ans et, comme mentionné dans d’autres commentaires, l’essentiel du travail ressemble à du SWE
Selon l’étape du projet, le travail quotidien varie, mais relève généralement de l’un des points suivants :
- collaboration avec les parties prenantes et les TPM, et élaboration d’hypothèses via l’analyse de données pour résoudre des problèmes business prioritaires
- formulation d’un problème business sous forme de problème ML, et création de métriques adaptées au modèle ML et au problème business
- construction de PoC et de prototypes pour valider la faisabilité technique de nouvelles fonctionnalités et idées
- rédaction de documents de conception pour l’architecture et les décisions techniques
- collaboration avec les équipes plateforme pour mettre en place et maintenir les pipelines de données selon les besoins des nouveaux projets ML et des projets existants
- construction, déploiement et maintenance de microservices ML pour l’inférence
- exécution d’A/B tests et rédaction de documents de conception pour l’analyse post-test
- mise en place de pipelines pour le réentraînement des modèles ML

jackspawn

Il consacre plus de 50 % de son temps au backend engineering
- Parce que le ML est utilisé au sein d’une API plus large
Il est responsable de l’expérience end-to-end de cette API
- Donc il fait tout ce qui apporte le meilleur rapport valeur/temps
- Et cela n’a souvent rien à voir avec les modèles ML

mardifoufs

Il travaille sur l’optimisation du code d’inférence et sur la « mise en produit » de modèles entraînés
Actuellement, il travaille sur de l’entraînement et de l’inférence en local, car il est dans un secteur où les services cloud ne sont pas encore couramment utilisés
- Comme ce n’est pas du LLM, il y a moins d’outils prêts à l’emploi, ce qui rend le travail intéressant
- Il faut construire beaucoup de choses soi-même
Son travail va de l’évaluation de la qualité des données (la partie locale est complexe) jusqu’à l’utilisation directe de CUDA
- Parce qu’il existe des bibliothèques de traitement du signal déjà construites sur CUDA dont il peut tirer parti
Cela inclut parfois aussi la création d’outils internes pour l’équipe (équipe mixte chercheurs/MLE)
- Comme c’est un domaine très niche, ils doivent construire eux-mêmes des outils pour visualiser les données et l’inférence
Il dispose d’une liberté totale sur les outils et la conception logicielle interne, ce qui lui a permis d’avoir beaucoup d’influence dans l’organisation
L’un des outils bricolés sur le vif va maintenant être intégré au produit phare

hirako2000

Ce n’est pas sa mission principale, mais il passe l’essentiel de son temps à « raccorder des morceaux »
- ajuster de l’open source existant
- trouver comment optimiser les ressources
- réentraîner des modèles sur d’autres datasets
- essayer d’exécuter du code Python mal écrit
- ajouter les fichiers de requirements manquants
- nettoyer les données
Il réfléchit à ce qui pourrait réellement être utilement résolu par le ML et qui ne l’a pas déjà été il y a des années
Il vérifie les prix actuels des GPU et calcule s’il vaut mieux en acheter plutôt que louer des créneaux coûteux chez un hébergeur
Il lit des articles de recherche jusqu’à en avoir mal à la tête
- en prenant le temps de lire le résumé et de survoler quelques schémas au milieu

tenache

Il a étudié le machine learning et a été recruté à l’origine pour ce rôle, mais l’entreprise a changé de direction et il travaille désormais sur des LLM
Il passe l’essentiel de son temps sur des tâches comme :
- comprendre comment fonctionnent différents LLM
- trouver les meilleurs paramètres
- comprendre comment faire du RAG (Retrieval-Augmented Generation)
- comprendre comment les intégrer avec d’autres bots

trybackprop

Sur une semaine donnée, il fait généralement le type de travail suivant :
15 % : réunions de discussion technique ou 1:1
- En général, pour discuter d’idées autour des modèles, de plans ou du support aux produits ML
40 % : développement ML
- Aux premières étapes d’un projet, il cherche à comprendre les exigences produit
- Il discute avec l’équipe des modèles ML ou des algorithmes qui pourraient aider à atteindre les objectifs produit / business
- Il récupère des datasets existants auprès d’analystes et de data scientists
- Il construit des pipelines à partir de ces datasets pour créer les jeux de données d’entraînement et de validation
- Pendant qu’il attend que ces jeux de données soient remplis (cela peut prendre jusqu’à 2 semaines), il travaille en parallèle sur d’autres projets plus ou moins avancés
- Il travaille aussi sur de nouveaux modèles (écrits en PyTorch), les teste sur de petits volumes de données pour évaluer les performances offline et juger s’ils se comportent comme prévu
- Il effectue quelques tests manuels avec le modèle pour remplir des informations produit et vérifier sa solidité (sans expérimentation à grande échelle, il faut s’appuyer sur son intuition et celle de l’équipe)
- Une fois les jeux de données d’entraînement/validation prêts, il entraîne les modèles sur de gros volumes de données, examine les résultats offline et, s’il y a des problèmes, ajuste le modèle ou change l’architecture
- Si les résultats offline sont bons ou semblent bons, il déploie le modèle en production pour expérimentation
- En parallèle, il peut modifier le code produit / infrastructure pour tester le nouveau modèle qu’il a construit
- Il lance les expériences et augmente lentement le trafic jusqu’à une allocation de 1 à 5 %, puis les laisse tourner plusieurs semaines ou un mois
- Pendant ce temps, il observe les résultats et surveille tous les pipelines concernés pour s’assurer que le modèle est correctement entraîné et que les résultats de l’expérience ne sont pas faussés par des facteurs d’infrastructure, des bugs ou des éléments produit imprévus
- Si les résultats semblent conformes aux attentes et cohérents avec l’hypothèse initiale, il discute avec l’équipe d’un lancement ; si la décision est prise, il lance !
  - (Remarque : le développement de modèle inclut la rédaction de features, la préparation des datasets, l’analyse, la création du modèle ML lui-même et l’implémentation de modifications dans le code produit / infrastructure)
20 % : maintenance
- Ce n’est pas parce qu’il développe de nouveaux modèles qu’il ignore les modèles existants
- Il les vérifie chaque jour pour s’assurer que les performances ne se dégradent pas ou ne changent pas de manière inattendue
- Il corrige aussi les pipelines et les rend plus efficaces
15 % : lecture de papiers de recherche et montée en compétences
- Le monde de l’IA / ML évolue vite, donc il lit en continu de nouveaux papiers et teste chez lui de nouvelles techniques pour rester à jour
- Comme cela lui plaît, il ne le vit pas comme un fardeau
- Il ne considère pas cela comme une corvée nécessaire pour rester à niveau
10 % : recherche interne
- Il utilise ce temps pour en apprendre davantage sur les autres produits de l’équipe ou de l’entreprise, et voir comment son équipe pourrait aider ou quelles techniques / approches elle pourrait leur emprunter
- Il l’utilise aussi pour prendre du recul sur le travail des 6 à 12 derniers mois et noter les enseignements tirés

4 commentaires

ohyecloudy 2024-06-17

L’expression « Les gens sans bagage technique me prennent pour un magicien, et moi je les vois comme des prêtres vaudous » est amusante.

nutella 2024-06-12

Les données... les données... je compatis.

halfenif 2024-06-10

C’est bien exactement ce que j’imaginais vaguement.

tttttaa 2024-06-10

C'est intéressant !