Intelligence artificielle

Data Science is Boring (Partie 1)

Data Science is Boring (Partie 1)


En bref, quand je dis que la science des données est ennuyeuse, je veux dire le sentiment de dégonflement quand on se rend compte de la écart entre l'attente romancée et la réalité.

La plupart des jeunes scientifiques de données s'attendent à passer la plupart du temps à bricoler et à construire des modèles fantaisistes ML ou à présenter des aperçus commerciaux novateurs avec des visualisations colorées. Bien sûr, ceux-ci font toujours partie du travail.

Mais à mesure que les entreprises sont mieux éduquées, elles se concentrent davantage sur les vraies valeurs opérationnelles. Ça signifie entreprises vouloir déployer plus de systèmes ML; ils se soucient moins du nombre de nouveaux modèles ou de tableaux de bord sophistiqués dont ils disposent. En conséquence, les scientifiques de données sont invités à effectuer les travaux non liés au niveau ML. Cela conduit à l'ennui.

Qualifions encore plus ce à quoi «ennuyeux» ressemble dans la science des données, ce sera très ennuyeux si je vous montre ma journée type du lundi au vendredi. Je vais donc catégoriser mon travail en plusieurs catégories, mettre en évidence les attentes par rapport à la réalité et partager mes mécanismes d'adaptation.

Je vais utiliser le récit "nous" parce que les exemples sont tirés d’un ensemble d’expériences et d’équipes. Les exemples ne sont peut-être pas exhaustifs, mais je pense qu'ils feront valoir leur point de vue.

3.1 Conception (5-10% du temps)

C’est à ce moment-là que nous obtenons collectivement «de haut niveau» intellectuellement pour résoudre des problèmes et proposer des idées brillantes. Ces idées peuvent inclure une nouvelle architecture de modèle, des fonctionnalités de données, une conception de système, etc. Très bientôt, nous atteindrons un point bas car nous devons choisir la solution la plus simple (et souvent la plus ennuyeuse) en raison de contraintes de temps et d'autres priorités.

Attendu: Nous mettons en œuvre des idées qui peuvent figurer dans des revues de premier plan telles que NIPS, le blog de Google AI Research, etc. Peut-être même gagner le prochain prix Nobel.

Réalité: Nous mettons en œuvre des choses qui font le travail bien. Nous prenons des photos de jolis dessins au tableau blanc qui méritent d’être encadrés.

Mécanisme d'adaptation: 1) Continuez à parler des idées folles autour d'un verre avec des amis en dehors de mon domaine; ils peuvent être brutalement honnêtes (et impolis) en fermant les idées folles, mais stupides, 2) font les idées folles et intelligentes en tant que projets parallèles, 3) il s'avère que la plupart des idées folles ne fonctionnent pas vraiment ou sont simplement légèrement mieux que les idées simples. Donc, valider et renforcer le principe KISS (Keep-It-Simple-Stupid) me donne toujours du réconfort et une fermeture.

3.2 Codage (20 à 70% du temps dépend du rôle)

Pas grand chose à dire ici. C'est à ce moment-là que nous mettons des écouteurs, sirotons un café, étirons nos doigts, verrouillons les écrans, tapons de belles lignes de codes et laissons la magie opérer.

Nos codes appartiennent généralement à cinq catégories (% du total des lignes de code): pipeline de données (50-70%), choses liées au système et à l'intégration (10-20%), modèle ML (5-10%), analyse pour la prise en charge du débogage et présentations (5 à 10%). C’est à peu près conforme aux observations faites par d’autres personnes. Voici une image plus grande.

La proportion du code modèle (illustratif) de Sergey Karayev dans son cours Full Stack Deep Learning (lien)

Comme vous pouvez le constater, nous passons le plus clair de notre temps à coder les trucs ennuyeux sans ML. Bien que le composant ML soit très critique, les frameworks modernes et les langages de codage (par exemple, Keras, XGBoost, Sklearn de Python, etc.) ont fait abstraction de la complexité. Cela signifie que l'obtention des résultats souhaités ne nécessite pas une base de code lourde, car le flux de travail est déjà bien normalisé et optimisé (l'optimisation de bas niveau est différente, mais c'est probablement 1% des cas).

Attendu: Vous passez la plupart du temps à développer et à affiner le composant ML; quelqu'un d'autre s'occupera du reste.

Réalité: Personne ne veut 1) faire des choses que vous ne voulez pas faire, 2) garder toutes les bonnes choses pour vous, et 3) vous consacrer un temps démesuré à un flux de travail déjà bien optimisé.

Mécanisme d'adaptation: Nous sommes fiers de déployer des systèmes ML qui conduisent de véritables opérations. Cela signifie faire tout ce qui est nécessaire au-delà du modèle. Oui, cela devient frustrant et ennuyeux. Ainsi, nous prenons tous l'initiative de prendre des décisions de conception en fonction de nos domaines et de notre expertise, ce qui garantit que nous exploitons nos atouts; nous développons certaines parties de la solution en supportant

3.3 QA, débogage et réparation Sh * t (au moins 65% du temps)

À mon avis, c'est la partie la plus ennuyeuse et la plus pénible de tout travail de développement technique. Le développement de systèmes ML n'est pas une exception.

Dans le contexte ML, il existe deux types de «bogues»: les mauvais résultats et les problèmes de logiciel traditionnels. Mauvais résultats faites référence à de faibles scores de modèle (par exemple, exactitude ou précision) ou à des prédictions insensibles (par exemple, les probabilités sont très biaisées en fonction de l'expérience professionnelle). Rien n’est faux avec le code, c’est juste que les résultats n’ont pas de sens ou ne sont pas assez bons. Problèmes de logiciels traditionnels inclure des choses comme le code cassé ou des problèmes de configuration du système.

Attendu: Nous devons juste gérer les mauvais résultats et penser à des moyens plus intelligents de construire de meilleurs modèles. Ceci est encore quelque peu engageant intellectuellement; il est également gratifiant de voir la performance augmenter grâce à de bonnes idées.

Réalité: Hors du temps que nous passons sur les correctifs QA / débogage / appliquer, environ 70 à 90% concernent des problèmes de logiciels traditionnels. Habituellement, nous pouvons obtenir un assez bon résultat assez rapidement après avoir construit le pipeline de validation de modélisation de modèle de bout en bout. Ensuite, nous modifions souvent les priorités en matière de modélisation pour nous concentrer sur les problèmes du système.

Mécanisme d'adaptation: Je gamifie et garde un «trophée» avec la fonction Problèmes de Github. Je ressens instantanément de la dopamine lorsque je ferme des tickets d’émission. Je suis fier de voir les problèmes que nous avons «conquis», plus fiers. Bien sûr, je suis plus fier si tout fonctionne comme par magie lorsque je clique sur «Go» - cela ne s'est produit qu'une seule fois dans une mission de programmation à l'université. Je me souviendrai de ce sentiment pour le reste de ma vie. Si cela se reproduit dans la vie réelle, quelque chose ne va probablement pas.

Un instantané du tableau des problèmes de Gibhut

3.4 Lutte contre le feu (10 à 50% du temps)

C’est un cauchemar pour tout responsable d’équipe de diffusion et elle n’est pas propre à la science des données. Peu importe la façon dont la chronologie a été pensée. Les choses arrivent toujours et vous mettent hors de propos. Pour être concret, les surprises peuvent être regroupées en trois catégories: une) problèmes externes comme le changement de portée, la dépendance du système en amont, et le client se plaint, b) questions concernant l'équipe interne comme un bogue ennuyeux qui prend beaucoup plus de temps à résoudre que prévu, les personnes recherchant un nouvel emploi et ne faisant pas la transition correctement, le manque de personnel, les conflits de personnalité, et c) ma propre ignorance, qui est un seau divers pour les «autres».

Attendu: croisière du début à la fin. Des hauts faits et des câlins de la part des clients, de votre patron et de votre équipe.

Réalité: des choses inattendues se produisent généralement dans les moments les plus difficiles. Il existe des schémas généraux, mais pas de formule fourre-tout, ce qui le rend frustrant.

Mécanisme d'adaptation: 1) multipliez le calendrier par 2-2,5x pour laisser suffisamment de marge de sécurité si elle concerne des problèmes techniques profonds ou des activités inter-équipes, 2) soyez agressif lors de la définition des jalons internes, 3) je jure fort dans mon esprit, eh bien, certains 4) respirer, sourire et écouter, 5) explorer toutes les options possibles avec l'équipe et établir des priorités en fonction de la faisabilité, des efforts et de la résistance, 6) si rien ne fonctionne, n'attendez pas, demandez de l'aide! 7) juste exécuter. Bon nombre d’entre elles ne sont pas des mécanismes d’adaptation en soi, mais ce sont de bonnes pratiques et elles fonctionnent bien.

Show More

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Related Articles

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Close
Close