L'ingénieur de plateforme

Pensez à l’ingénieure du son lors d’un concert. Elle connaît chaque câble, chaque haut-parleur et chaque microphone. Si quelque chose tombe en panne pendant le spectacle, elle le répare en quelques secondes. Sans elle, il n’y a pas de concert. Mais elle ne choisit pas les chansons et ne décide pas comment les jouer.

Beaucoup d’ingénieurs MLOps sont dans cette situation. Ils viennent du DevOps. Ils créent les pipelines, les registres, les modèles de déploiement et les tableaux de bord. Ces outils permettent aux scientifiques des données de mettre des modèles en production. Souvent, ils exploitent plus de modèles que toute autre personne dans l’entreprise. Mais quelqu’un d’autre choisit ce que chaque modèle prédit, comment l’évaluer et quand il est assez bon.

Ils postulent à des postes d’ingénieur en apprentissage automatique parce que le titre semble être la prochaine étape. Souvent, ils veulent aussi prendre ces décisions eux-mêmes. Suivez Wei pendant l’entrevue approfondie sur l’apprentissage automatique. Observez où son expérience des plateformes excelle. Voyez ce qui arrive quand Ioana lui demande de réfléchir comme le responsable d’un modèle.

WZ

La personne candidate

Wei Zhang

Ingénieur MLOps, 3 ans, après 7 ans en DevOps

• 10 ans en infrastructure
• 3 ans en MLOps
• Certification CKA
• Toronto, Ontario

• Ingénieur MLOps, Harbourline Insurance, Toronto (de 2023 à aujourd’hui). Création d’une plateforme MLOps de bout en bout exploitant plus de 40 modèles sur Kubernetes (EKS) : Kubeflow Pipelines, MLflow, KServe, Feast.
• Réduction du délai de déploiement des modèles d’environ 6 semaines à 2 jours grâce à des modèles CI/CD (intégration et déploiement continus) standard (GitHub Actions, Argo CD).
• Mise en place d’un feature store (magasin de caractéristiques) avec Feast pour 12 modèles, avec des données d’entraînement respectant les valeurs disponibles à chaque moment.
• Surveillance des modèles avec Prometheus, Grafana et Evidently. Infrastructure sous forme de code avec Terraform.
• Ingénieur DevOps principal, Tallis Freight, Toronto (de 2016 à 2023). Migration de 60 services vers Kubernetes; CI/CD; responsable de l’équipe de garde pendant deux ans.
• Maîtrise en informatique (2015). Certified Kubernetes Administrator; AWS Solutions Architect Professional.
• Python, Go, Bash, Terraform, Docker, Kubernetes, Kubeflow, MLflow, KServe, Feast, Airflow, Spark, Prometheus, Grafana, Evidently, PyTorch, scikit-learn, XGBoost.

Ce qu’Ioana voit avant l’appel

Ioana aime ce CV et l’examine avec attention. La plateforme de Fennick utilise exactement ce type d’outils : Kubernetes, MLflow et un magasin de caractéristiques développé à l’interne. Wei pourrait réparer la tâche de réentraînement qu’un seul ingénieur comprend. Mais le poste consiste à être responsable du modèle d’heure d’arrivée prévue. Le CV ne dit presque rien sur les décisions liées aux modèles. La liste de compétences se termine par PyTorch, scikit-learn et XGBoost. Le CV ne permet pas à Ioana de savoir si Wei les a utilisés ou déployés.

Elle note ce qu’elle veut découvrir :

• « Plus de 40 modèles. » Combien sont réellement utilisés? Qu’a-t-il créé, et qu’ont créé les scientifiques des données?
• Choisir un modèle. Peut-il expliquer l’étiquette, la mesure et les raisons de ces choix? Qui a décidé?
• Surveillance. Quand le tableau de bord a montré une dérive, qu’est-il arrivé ensuite?
• Pour le problème de Fennick : s’intéresse-t-il à ce que le modèle devrait prédire, ou seulement à son fonctionnement?

Termes utilisés sur cette page

• MLOps : le travail d’exploitation des modèles d’apprentissage automatique en production : pipelines, déploiement, surveillance et réentraînement.
• Kubeflow Pipelines : un outil qui exécute des flux de travail d’apprentissage automatique par étapes sur Kubernetes. Par exemple : obtenir les données, entraîner, évaluer, enregistrer.
• Registre de modèles MLflow : un endroit qui stocke les versions des modèles et indique laquelle est en production. Les versions actuelles de MLflow utilisent des alias comme « champion » pour cela.
• Champion et challenger : le modèle en production (champion) et un nouveau modèle qui doit le surpasser avant de le remplacer (challenger).
• Magasin de caractéristiques : un système qui calcule les caractéristiques une seule fois, puis les fournit pour l’entraînement et les prédictions en direct. Une jointure temporelle donne à chaque exemple d’entraînement seulement les valeurs des caractéristiques qui existaient à ce moment-là.
• Déploiement canari : une nouvelle version reçoit d’abord une petite partie du trafic, pour que les problèmes touchent peu d’utilisateurs. Mode fantôme : le nouveau modèle traite le trafic réel, mais personne ne voit sa sortie.
• Prédiction de quantile : le modèle prédit une valeur sous laquelle se situeront, par exemple, 90 % des résultats. Pour un délai de livraison, cela signifie « 90 % des commandes arrivent avant ce délai ».
• Écart entre l’entraînement et la mise en service : une caractéristique est calculée d’une façon pour l’entraînement et d’une autre en production.

L’entrevue

Minutes 0 à 5 : l'ouverture

Ioana(intervieweur) :

Bonjour Wei. Désolée, j’ai une minute de retard, la réunion d’avant a duré plus longtemps. Alors, je suis Ioana, ingénieure principale en apprentissage automatique. J’ai créé le service ETA, le délai de livraison dans l’application. Aujourd’hui : vous me parlez d’un modèle sur lequel vous avez travaillé en production, je pose beaucoup de questions. Ensuite, un problème de notre côté, puis vos questions. Et s’il vous plaît, pas d’assistants d’IA pour cette étape. Les notes sur papier sont permises.

Wei(personne candidate) :

Ça me va. Juste pour vous prévenir, mon domaine, c’est plutôt la plateforme. Mais je veux bien entrer dans les détails.

Ioana(intervieweur) :

Pas de problème. On verra où ça nous mène.

Minutes 5 à 25 : la plateforme, puis un modèle

Wei(personne candidate) :

Alors, quand je suis arrivé chez Harbourline, chaque modèle passait en production différemment. Un scientifique des données terminait un carnet (notebook) Jupyter, puis ouvrait un billet de soutien. Quelqu’un en TI lui préparait un serveur. Ça prenait environ six semaines, et personne ne pouvait dire quel code avait produit quel modèle. J’ai donc créé un parcours standard. L’entraînement s’exécute dans un pipeline Kubeflow. Chaque exécution consigne ses données dans MLflow. Si le nouveau modèle réussit les vérifications, on l’enregistre, et Argo CD le déploie sur KServe. Les caractéristiques viennent de Feast. Maintenant, un scientifique des données peut passer d’une demande de tirage (pull request) fusionnée à la production en deux jours environ.

Ioana(intervieweur) :

Bien. Votre CV parle de plus de 40 modèles. Combien sont vraiment utilisés chaque jour?

Wei(personne candidate) :

Hmm. Bonne question. Environ 40 sont déployés. Vraiment utilisés chaque jour… peut-être 15? Certains sont d’anciennes versions que les équipes ont oublié de désactiver. Je leur demande régulièrement.

Ioana(intervieweur) :

D’accord. Prenons un des quinze, celui que vous connaissez le mieux.

Wei(personne candidate) :

Le modèle de détection de fraude dans les réclamations automobiles. Quand un client fait une réclamation automobile, il donne un score. Les scores élevés vont à l’équipe d’enquête.

Ioana(intervieweur) :

Quelle est la cible?

Wei(personne candidate) :

Il est sur KServe, dans notre grappe de production, avec deux répliques et une mise à l’échelle automatique.

Ioana(intervieweur) :

Ah, désolée, je veux dire… l’étiquette. Que prédit le modèle? C’est quoi, un « oui » dans les données d’entraînement?

Wei(personne candidate) :

Ah, désolé, j’avais compris la cible de déploiement. Il rit. L’étiquette… une réclamation frauduleuse. Je pense que ce sont les réclamations que l’équipe d’enquête a confirmées comme frauduleuses.

Ioana(intervieweur) :

Seulement celles qu’ils ont examinées?

Wei(personne candidate) :

Je pense que oui.

Ioana(intervieweur) :

Donc, une fraude que personne n’a examinée, c’est un « non » dans les données.

Wei(personne candidate) :

Hmm. Oui, si ça fonctionne comme je pense. Je n’y avais jamais pensé. Je ne sais pas comment les scientifiques des données ont géré ça. Ils ont peut-être fait quelque chose, je ne sais pas.

Comment Ioana approfondit le sujet

Ioana pose une seule question sur l’étiquette, et cela révèle un vrai problème. Si seules les réclamations examinées peuvent être une « fraude », le modèle apprend ce que les enquêteurs ont examiné auparavant. Il n’apprend pas à reconnaître toutes les fraudes. Les responsables d’un modèle y pensent chaque jour. Wei voit le problème quand on le lui signale, mais il n’a jamais eu à y réfléchir.

Ioana(intervieweur) :

D’accord. Comment une nouvelle version de ce modèle passe-t-elle en production?

Wei(personne candidate) :

Cette partie, je la connais bien. Le pipeline entraîne le modèle sur un instantané des données, puis l’évalue sur des données réservées. Il y a une barrière : l’AUC du nouveau modèle ne doit pas être inférieure à celle du champion moins 0,01. S’il la franchit, il reçoit l’alias « challenger » dans MLflow. Ensuite, un scientifique des données approuve, et il devient champion. Argo CD le déploie.

Ioana(intervieweur) :

Qui a choisi l’AUC?

Wei(personne candidate) :

La scientifique des données qui travaille sur ce modèle. J’ai créé la barrière pour que chaque équipe puisse définir sa propre mesure et son seuil. Elle m’a donné l’AUC et 0,01.

Ioana(intervieweur) :

Si vous étiez responsable de ce modèle, garderiez-vous l’AUC?

Wei(personne candidate) :

Pause. Je ne sais pas. L’AUC, c’est la mesure standard, non? Honnêtement, je ne lui ai jamais demandé pourquoi. J’aurais dû.

Ioana(intervieweur) :

Peut-être un indice. Combien de réclamations l’équipe d’enquête peut-elle examiner en une journée?

Wei(personne candidate) :

Pas beaucoup. Peut-être 30, 40? Donc… ce qui compte, c’est le haut de la liste? Si les 40 premières sont bonnes, le reste compte moins. Je ne sais pas trop comment s’appelle la mesure pour ça.

« Les scientifiques des données décident »

Dans un rôle lié à la plateforme, c’est une façon normale de travailler. Dans une entrevue d’ingénieur en apprentissage automatique, c’est la réponse qui nuit le plus. L’offre d’emploi demande une personne responsable du modèle. Wei a trouvé une bonne idée avec un indice, mais il n’avait jamais demandé pourquoi cette mesure avait été choisie. Si vous travaillez avec des modèles, demandez à leurs responsables « pourquoi? » pour chaque choix. Vous pourrez ensuite l’expliquer en entrevue, même si vous n’avez pas pris la décision.

Ioana(intervieweur) :

D’accord. Maintenant, autre chose. Imaginez que le modèle de fraude donne un score étrange en production et que les enquêteurs se plaignent. Pouvez-vous me dire exactement quelles données et quel code ont produit ce modèle?

Wei(personne candidate) :

Oui, tout à fait. On consigne chaque prédiction avec la version du modèle. La version pointe vers l’exécution MLflow. L’exécution contient le commit Git (la version enregistrée du code), l’image… et le chemin de l’instantané des données.

Ioana(intervieweur) :

Et les données sont encore là?

Wei(personne candidate) :

Je pense qu’on les garde deux ans. Il faudrait que je vérifie. Mais oui, je peux reconstruire exactement le même modèle. La dernière fois qu’on me l’a demandé, ça m’a pris peut-être deux heures.

Ioana(intervieweur) :

Bien. C’est mieux que ce qu’on a.

Les forces de Wei

C’est une réponse claire, qui vient d’un vrai travail. Wei connaît la chaîne qui relie une prédiction au code et aux données, ainsi que le temps nécessaire pour reconstruire le modèle. Beaucoup de candidats en apprentissage automatique ne peuvent pas répondre à cette question. Pour un auditeur, ou lors d’un incident à 2 h du matin, cette chaîne est très précieuse. Ioana le souligne.

Ioana(intervieweur) :

Et la surveillance. Votre CV mentionne Evidently. Qu’est-ce qui se passait quand il montrait une dérive?

Wei(personne candidate) :

Les rapports vont à l’équipe de science des données chaque semaine. Honnêtement? Souvent, rien. Beaucoup de rapports étaient toujours rouges, alors les gens ont arrêté de les lire.

Ioana(intervieweur) :

Pourquoi étaient-ils toujours rouges?

Wei(personne candidate) :

On utilisait la vérification de dérive par défaut pour chaque caractéristique. Mais beaucoup de caractéristiques changent chaque semaine de toute façon, avec les jours de paie, les jours fériés. Donc presque tout était rouge.

Ioana(intervieweur) :

Qui devrait décider quels changements comptent?

Wei(personne candidate) :

Quelqu’un qui sait quels changements comptent pour le modèle. Pause. C’est le responsable. Et ce n’était pas moi.

Une réponse honnête sur son propre système

Wei aurait pu dire « nous surveillions la dérive avec Evidently ». Il a dit que personne ne lisait les rapports, et il a expliqué pourquoi. Cette honnêteté rend ses bonnes réponses plus crédibles. Et sa dernière phrase montre qu’il voit déjà l’écart entre faire fonctionner un modèle et en être responsable.

Minutes 25 à 48 : le problème de Fennick

Ioana(intervieweur) :

D’accord, maintenant un vrai problème de notre côté. Les clients voient un délai de livraison dans l’application avant de payer. À l’heure du souper et quand il fait mauvais, notre estimation est trop optimiste. Les jours normaux, environ 9 % des commandes arrivent plus de dix minutes après l’heure estimée. Ces jours-là, c’est environ 18 %. Les gens sont fâchés, les billets de soutien augmentent. Comment aborderiez-vous ce problème?

Wei(personne candidate) :

D’accord. D’abord, je veux voir ce qui se passe. Avez-vous un tableau de bord des commandes en retard par ville et par heure, avec des alertes?

Ioana(intervieweur) :

On a l’erreur après la livraison, dans un rapport le lendemain matin. Pas d’alertes.

Wei(personne candidate) :

Alors, c’est la première chose. Le taux de retard par ville et par heure, en temps réel, avec une alerte quand il dépasse, disons, 12 %. Et on réentraîne le modèle chaque semaine, c’est ça? Je le réentraînerais chaque jour. J’en ferais un pipeline avec une barrière entre champion et challenger, pour le faire chaque jour sans risque.

Ioana(intervieweur) :

D’accord. Est-ce que le réentraîner chaque jour réglerait le problème du souper?

Wei(personne candidate) :

Il utiliserait des données plus récentes…

Ioana(intervieweur) :

Mais le souper revient chaque jour.

Wei(personne candidate) :

Oui. Pause. Donc les données de la semaine contiennent déjà sept soupers. Hmm. Alors non, probablement pas. Sauf si quelque chose a changé cette semaine, comme un nouveau magasin. Je pense que je suis allé vers la partie que je connais.

Se tourner vers les outils

La première réponse de Wei porte sur les tableaux de bord et la fréquence du réentraînement. Les deux sont utiles, et les deux concernent le fonctionnement du modèle. Ni l’un ni l’autre ne change ce que le modèle prédit. Quand on vous présente un problème de modèle, demandez d’abord ce que le modèle devrait faire, puis comment le faire fonctionner. Wei l’a remarqué lui-même, ce qui est bien.

Ioana(intervieweur) :

Essayons autre chose. Imaginez qu’il n’y a pas de scientifiques des données. Vous êtes responsable de ce modèle. Le gestionnaire de produit vient vous demander : quel nombre devrait-on montrer au client? Que dites-vous?

Wei(personne candidate) :

Le plus exact?

Ioana(intervieweur) :

D’accord. Que veut dire « exact » quand une commande arrive dix minutes en retard, et une autre dix minutes en avance?

Wei(personne candidate) :

Pour l’erreur, c’est pareil. Pour le client… non. Le retard, c’est pire. En avance, personne ne se plaint.

Ioana(intervieweur) :

Alors, qu’est-ce que vous montrez?

Wei(personne candidate) :

Peut-être ajouter une marge? À l’heure du souper, ajouter quelques minutes.

Ioana(intervieweur) :

Combien de minutes? Et quand il pleut?

Wei(personne candidate) :

Hmm. Je prendrais les commandes du souper du mois dernier et je choisirais une marge pour que la plupart arrivent à temps. Disons 90 %. Et une autre pour la pluie. Et la neige. Et peut-être par ville… Pause. Mais alors les marges deviennent un deuxième modèle par-dessus le modèle. Ce n’est pas agréable à maintenir.

Ioana(intervieweur) :

Oui. C’est la bonne inquiétude. Ce que vous avez décrit, c’est le 90e centile. Vous pouvez entraîner le modèle à prédire ce point directement, en intégrant la météo au modèle : la régression quantile. L’avez-vous utilisée?

Wei(personne candidate) :

J’ai vu le terme. Peut-être dans un fichier de configuration. Je ne pourrais pas expliquer comment ça fonctionne.

Une meilleure réponse, à partir des connaissances de Wei

Wei n’avait pas besoin de connaître la régression quantile pour donner une bonne réponse. Il devait partir du client, pas du pipeline :

« Si j’en suis responsable, je demande d’abord ce que le nombre signifie pour le client. Le retard est pire que l’avance, alors je ne montrerais pas la moyenne. Je montrerais un délai que la plupart des commandes respectent, disons 85 ou 90 %. Je demanderais à l’équipe produit combien de commandes on perd avec des délais plus longs. Ensuite, je vérifierais séparément pour le souper et pour la pluie. Je sais qu’il existe des façons d’entraîner un modèle directement pour ça; je devrais me documenter. Ensuite, le réentraînement et les tableaux de bord, que je peux construire rapidement. »

Cette réponse reconnaît honnêtement ses lacunes, tout en montrant la façon de penser d’un responsable.

Ioana est ensuite passée aux questions de production, et Wei a de nouveau répondu rapidement.

Minutes 38 à 48 : mise en service, écarts et tests

Ioana(intervieweur) :

L’application appelle le service ETA chaque fois qu’on affiche la page de paiement. Environ 1,5 million d’appels par jour. Notre budget de latence est de 50 millisecondes au p95. Désolée, p99. Au p99.

Wei(personne candidate) :

D’accord. Ces 50 millisecondes sont mesurées au service, ou dans l’application?

Ioana(intervieweur) :

Au service.

Wei(personne candidate) :

Bien, donc le réseau jusqu’au téléphone n’est pas inclus. Le modèle est rapide; le risque, c’est la récupération des caractéristiques. Je mettrais un délai maximal pour chaque récupération, et une solution de repli. Pour la durée, je regarderais d’abord la vitesse des récupérations aujourd’hui, au p99, et je resterais au-dessus. Si une caractéristique en temps réel n’arrive pas, on utilise la dernière valeur connue, ou une valeur par défaut. Et une alerte sur la fréquence d’utilisation du repli, parce qu’un repli silencieux est un problème de qualité.

Pourquoi cela fonctionne

Wei demande où les 50 ms sont mesurées avant de concevoir quoi que ce soit. Cette seule question montre des années de travail en production. Sa conception convient aussi à l’utilisateur : la page de paiement ne doit jamais attendre une caractéristique lente à récupérer. Et il sait qu’un repli que personne ne compte cache des problèmes.

Ioana(intervieweur) :

D’accord. L’an dernier, on a eu un bogue d’écart entre l’entraînement et la production. Une caractéristique venait d’une table mise à jour par lots toutes les 15 minutes pendant l’entraînement. En production, elle venait de décomptes en temps réel. Six semaines avant qu’on le remarque.

Wei(personne candidate) :

Six semaines, c’est long. Donc deux sources différentes pour une caractéristique. Un magasin de caractéristiques aide si les deux parcours utilisent vraiment la même définition. Mais si le traitement par lots et le flux calculent les « commandes en attente » différemment, le magasin ne l’empêche pas. Je consignerais donc aussi les valeurs que le service a vraiment utilisées. Puis je les comparerais aux valeurs d’entraînement pour les mêmes commandes.

Ioana(intervieweur) :

D’accord. Dernière question là-dessus. Vous avez un nouveau modèle. Comment le testez-vous avec de vrais clients?

Wei(personne candidate) :

D’abord, en mode parallèle (shadow mode), sans afficher ses résultats. Le nouveau modèle traite tout le trafic, on consigne sa prédiction, personne ne la voit. Après la livraison, on compare les deux modèles aux délais réels. Ensuite, un déploiement canari sur 5 % du trafic, et on surveille les erreurs et la latence.

Ioana(intervieweur) :

Le mode parallèle est une bonne première étape. Le canari vous dit que le service est sûr. Vous dit-il si les clients sont plus satisfaits?

Wei(personne candidate) :

La vidéo se fige un instant. …désolé, votre image s’est figée. Pouvez-vous répéter la dernière partie?

Ioana(intervieweur) :

Le canari vous dit-il si les clients sont plus satisfaits? Moins de commandes en retard, le même nombre de commandes?

Wei(personne candidate) :

Pas vraiment. 5 % pendant quelques jours, c’est pour la sécurité. Pour mesurer l’effet, il faut une expérience. Chez Harbourline, je répartissais le trafic avec des indicateurs de fonctionnalité, et les scientifiques des données faisaient l’analyse. Je n’en ai jamais conçu une moi-même.

Ioana(intervieweur) :

D’accord. Ici, c’est aussi plus difficile, parce que les livreurs sont partagés entre les clients. Mais laissons ça de côté.

Mode parallèle

Le mode parallèle est une excellente première étape pour le modèle ETA, et Wei l’a proposé de lui-même. Le délai réel de livraison arrive en moins d’une heure. Quelques jours en parallèle permettent donc une comparaison valable sur des données en production, sans risque pour les clients. Ce que le mode parallèle ne peut pas montrer, c’est la réaction des clients à un nombre différent. Il faut une expérience pour cela, et Wei dit honnêtement qu’il n’en a jamais conçu.

Wei a demandé comment le réentraînement fonctionne aujourd’hui. Ioana lui a répondu honnêtement : une tâche cron qu’un seul ingénieur comprend vraiment. Il a aussi posé des questions sur les périodes de garde. C’est une semaine sur cinq, et il a dit que cela lui convenait, après des années à le faire.

Minutes 48 à 57 : les questions de Wei

Wei(personne candidate) :

À propos du réentraînement. Je pourrais en faire un vrai pipeline en un mois. Avec la barrière, le registre, tout ça.

Ioana(intervieweur) :

Je vous crois. Honnêtement, dans ce rôle, ça représente peut-être 20 %. Le gros du travail, ce sont les décisions sur le modèle, comme mes questions aujourd’hui.

Wei(personne candidate) :

Pause. D’accord. Merci, c’est utile. Et honnêtement, les décisions, c’est la partie que je veux apprendre. C’est pourquoi j’ai postulé. Je n’ai simplement pas encore cette compétence.

Entendre une réponse difficile

Ioana a dit à Wei, avec gentillesse et franchise, que ses meilleures compétences représentent une petite partie de ce poste. Wei n’a pas contesté ni exagéré ses capacités. Il a accepté, et il a dit ce qu’il veut. Ce n’est pas un moment de faiblesse. C’est le moment où les deux côtés ont le plus appris. Voir Une entrevue va dans les deux sens.

Minutes 57 à 60 : la conclusion

Ioana(intervieweur) :

Merci, Wei. Chantal vous communiquera les prochaines étapes cette semaine.

Wei(personne candidate) :

Merci. Et la question sur l’étiquette du modèle de fraude, je vais la poser lundi.

Après l’appel : les notes d’Ioana

Wei Zhang, entretien approfondi en apprentissage automatique

• Déploiement, reproductibilité, fiabilité : preuves solides. Chaîne complète reliant une prédiction au code, à l’image et à un instantané des données; modèle reconstruit en environ deux heures. A demandé où les 50 ms sont mesurées; délais d’expiration et solution de repli avec compteur.
• Écarts entre entraînement et service, magasins de variables : preuves solides. Sait qu’un magasin de variables seul n’empêche pas deux calculs différents; journaliser les variables utilisées et les comparer. A proposé de lui-même un mode parallèle sans effet sur les résultats.
• Surveillance : quelques preuves. L’a mise en place. A reconnu honnêtement que personne n’agissait sur les résultats, et compris pourquoi : quelqu’un doit être responsable des seuils.
• Responsabilité du modèle (étiquette, métrique, « assez bon ») : aucune preuve. Ne savait pas comment les étiquettes de fraude étaient créées ni pourquoi l’AUC avait été choisie. « Les scientifiques des données décident. »
• Définition du problème d’heure d’arrivée estimée : préoccupation. A commencé par les tableaux de bord et le réentraînement. Avec de l’aide, est arrivé à une marge, puis à l’idée d’un percentile. Ne connaissait pas la régression quantile.
• Expériences en ligne : aucune preuve. A construit la répartition du trafic, mais n’a jamais conçu de test.
• CV : « Plus de 40 modèles » signifie environ 40 modèles déployés, dont environ 15 utilisés chaque jour. Il l’a précisé tout de suite.

Recommandation : non pour ce poste. Excellentes compétences en plateforme, et très honnête. Ce poste exige de prendre la responsabilité des modèles, ce qu’il n’a pas encore fait. Ce serait une excellente recrue pour l’équipe ML Platform, s’il le souhaite.

La suite

L’entretien de conception de systèmes avec Ben a montré le même profil. Wei était parmi les meilleurs candidats pour le service des modèles, le déploiement progressif et la gestion des défaillances. Il a eu besoin d’aide quand Ben lui a demandé ce que le modèle devait optimiser. La conversation avec Laura sur les valeurs a été positive. Elle a aimé ses récits calmes d’incidents pendant ses périodes de garde.

Pendant le bilan, la décision a été rapide : non pour ce poste. Ravi a appelé Wei lui-même et lui a donné ses commentaires en deux phrases : « Vous avez d’excellentes compétences en plateforme. Ce poste exige de prendre la responsabilité des modèles, et nous n’en avons pas encore vu assez. »

Ravi avait mentionné l’équipe ML Platform lors de leur premier appel, et il en a reparlé. L’équipe recrutait, et Ioana avait recommandé Wei. Wei l’a remercié, puis a parlé franchement : « Je travaille sur les plateformes depuis dix ans. Je pourrais bien faire ce travail. Mais j’ai postulé parce que je veux être responsable des modèles. Si je prends un autre poste en plateforme maintenant, je ne l’apprendrai pas. Qu’est-ce que je devrais étudier? » Wei a donc refusé le poste dans l’équipe ML Platform.

Ravi a demandé conseil à Ioana. La semaine suivante, elle a transmis une courte liste par Chantal :

• Construisez un modèle du début à la fin en choisissant l’étiquette, la métrique et la référence de base. Notez vos raisons. Utilisez un jeu de données public qui contient une dimension temporelle.
• Apprenez les métriques de régression, les prédictions de quantiles et la façon de les vérifier par groupe.
• Apprenez les bases de la conception d’expériences, et pourquoi un test par client échoue quand les clients partagent quelque chose.
• Au travail, demandez à prendre les décisions de surveillance d’un modèle : quelles variables comptent, quels seuils utiliser, que faire quand une alerte se déclenche.

Wei a commencé par le dernier point. Il est allé voir la scientifique des données responsable du modèle de fraude et lui a posé des questions sur les étiquettes. Elle était contente de lui expliquer. Ils ont découvert que le modèle n’avait pas été vérifié sur des réclamations sortant des profils habituels des enquêteurs. Wei a proposé d’aider à faire l’analyse. Il n’a pas postulé de nouveau chez Fennick cette année-là. Il a dit qu’il postulerait à des postes d’ingénieur en apprentissage automatique lorsqu’il pourrait répondre aux questions d’Ioana sur son propre modèle.

C’est une bonne conclusion, même sans offre. Wei est reparti avec des commentaires clairs, un plan clair et aucune fausse image de ses compétences. Toutes les entrevues ne sont pas un pas vers cette entreprise. Certaines sont un pas vers la suivante. Consultez Continuer à apprendre, sans perdre de vue son objectif.

Ce qu’il faut en retenir

• Faire fonctionner un modèle n’est pas la même chose qu’en être responsable. Wei savait tout du fonctionnement du modèle de fraude, mais presque rien des raisons de sa conception. Les entrevues d’ingénieur en apprentissage automatique cherchent à vérifier ce deuxième aspect.
• Demandez « pourquoi » à propos des modèles que vous côtoyez. Si votre travail vous rapproche des décisions sur les modèles, demandez aux responsables pourquoi ils ont choisi chaque étiquette, métrique et seuil. Vous pourrez ensuite l’expliquer, même sans avoir pris la décision.
• Écoutez la question avant d’y répondre. « Cible » avait un sens différent pour Wei. Une courte question aurait fait gagner quelques secondes : « Vous parlez de l’étiquette ou du déploiement? » Ça arrive à tout le monde.
• Face à un problème de modèle, commencez par ce que le modèle doit faire. Les tableaux de bord et le réentraînement sont utiles, mais ils viennent après.
• L’honnêteté est utile dans les deux sens. Les aveux de Wei, « peut-être 15 sont vraiment utilisés » et « personne ne lisait les rapports », rendaient ses bonnes réponses crédibles. L’honnêteté d’Ioana au sujet des 20 % l’a aidé à décider ce qu’il veut vraiment.

Si votre profil ressemble à celui de Wei

1. Réécrivez votre CV en deux parties : ce que vous avez construit et ce que font les modèles. « Création de la plateforme de déploiement et de surveillance pour environ 40 modèles (15 utilisés chaque jour) » est plus convaincant que « plus de 40 modèles », parce que vous pouvez le justifier.
2. Apprenez à bien connaître un modèle de votre entreprise. Demandez une heure à son responsable : l’étiquette, la séparation des données, la référence de base, la métrique, le seuil et les problèmes de l’an dernier. Prenez des notes et exercez-vous à l’expliquer.
3. Construisez un modèle dont vous prenez les décisions. Choisissez un jeu de données public avec une dimension temporelle, une séparation chronologique et une référence de base simple. Traduire un besoin, Définir une référence de base et Les métriques de régression couvrent ces décisions. L’étude de cas Prévoir la demande de vélopartage est un bon point de départ. Vous pouvez y ajouter un modèle de régression quantile.
4. Apprenez à vérifier un modèle par groupe. L’analyse par sous-groupes et Seuils et calibration montrent ce qu’un responsable examine après le score global.
5. Transformez vos compétences en plateforme en réponses de responsable de modèle. Vous connaissez les outils de surveillance. Exercez-vous maintenant à expliquer quoi surveiller pour un modèle, à quel seuil, et quoi faire quand une alerte se déclenche. Planifier les vérifications en production vous aide.
6. Décidez ce que vous voulez avant de postuler. Si vous voulez un poste dans l’équipe ML Platform, votre CV est déjà solide. Si vous voulez être responsable des modèles, postulez quand vous pourrez expliquer un modèle, de l’étiquette à la surveillance.