Questions d'entretien Ingénieur Machine Learning

Le cycle de vie commence bien avant toute modélisation. Je commence par travailler avec les parties prenantes pour bien cadrer le problème : quelle décision le modèle doit-il appuyer, que signifie concrètement une bonne performance pour le business, et quelles données sont disponibles avec quelle qualité ? Une fois le problème cadré, je construis d'abord une baseline simple, car un modèle linéaire bien calibré surpasse souvent une implémentation médiocre de réseau de neurones et donne un point de référence à améliorer. Pour la production, je conçois l'infrastructure de service en parallèle du modèle, pas en dernier lieu. Je mets en place la supervision dès le premier jour : détection de dérive des données, suivi de la distribution des prédictions et latence. Je planifie aussi le réentraînement et définis les conditions de déclenchement à l'avance. La chose la plus importante que j'ai apprise est que le modèle n'est généralement pas le goulot d'étranglement : la qualité des données, le feature engineering et la fiabilité du service comptent davantage.

Je traite le feature engineering comme de la connaissance du domaine encodée dans du code. Les meilleures features viennent généralement d'une compréhension approfondie du problème et des données. Ma première étape est toujours de parler aux experts du domaine et de comprendre quels signaux ils pensent importants, puis de tester si ces signaux ont une valeur prédictive. Je suis rigoureux pour prévenir la fuite de données, ce qui signifie définir une frontière temporelle stricte pour les données de séries chronologiques. J'utilise des transformations stables en production. Je préfère moins de features bien comprises car elles sont plus faciles à déboguer quand quelque chose va mal. Je documente chaque feature avec sa source, sa transformation et ses limitations connues.

Les métriques hors ligne seules ne suffisent pas. J'utilise une évaluation en plusieurs étapes. D'abord, je vérifie que les métriques hors ligne sur l'ensemble de test respectent le seuil convenu avec les parties prenantes, et j'examine les performances sur les sous-groupes pertinents pour détecter un impact disparate. Ensuite, je fais un déploiement fantôme, en dirigeant le trafic réel vers le nouveau modèle sans utiliser ses prédictions, pour vérifier que l'infrastructure de service fonctionne et que la latence est acceptable. Enfin, je réalise un test A/B ou un déploiement progressif, en commençant par un petit pourcentage de trafic. Je mets en place des déclencheurs de rollback automatiques. Un modèle est prêt pour la production quand je fais autant confiance à la supervision qu'au modèle lui-même.

J'ai construit un modèle de prédiction du churn qui performait bien hors ligne mais a enregistré une chute significative de précision dans le premier mois après le lancement. La cause racine était une dérive de distribution : un changement produit avait modifié le comportement des utilisateurs d'une façon qui rendait les données d'entraînement historiques moins représentatives. Le correctif a consisté à ajouter une supervision de dérive des données à notre pipeline de features, à implémenter un réentraînement hebdomadaire automatique déclenché par la détection de dérive, et à mettre en place des alertes sur la distribution des prédictions. J'ai aussi introduit une fiche modèle avec des déclarations explicites sur les conditions de validation. La leçon est qu'un modèle est un composant dans un système changeant et a besoin du même investissement opérationnel que tout autre service de production.

Je présentais les résultats d'une évaluation de modèle de tarification à une équipe de direction. Le modèle avait de meilleures performances sur notre métrique principale mais de moins bonnes performances sur une métrique d'équité pour un segment client spécifique. J'ai restructuré la présentation autour d'une seule question : "doit-on déployer ce modèle ?" J'ai montré visuellement le compromis et j'ai cadré la constatation d'équité comme un risque business ainsi qu'une préoccupation éthique, ce qui a transformé la conversation d'une discussion technique en une décision sur les valeurs de l'entreprise. Nous avons convenu de reporter le déploiement jusqu'à l'investigation de la question d'équité. La réunion a mieux fonctionné parce que je l'ai traitée comme une réunion de décision, pas une présentation.

J'ai hérité d'un système de recommandation en production depuis 18 mois, non réentraîné depuis six mois, avec un taux de clics en baisse constante. Plutôt que de réentraîner immédiatement, j'ai d'abord investigué : deux features importantes avaient dérivé de façon significative suite à une expansion du catalogue, et le modèle sur-recommandait un ensemble étroit d'articles populaires. J'ai reconstruit le pipeline de features, ajouté un régularisateur de diversité à l'objectif d'entraînement, et mis en place une suite d'évaluation hors ligne mesurant à la fois la pertinence et la diversité. Après réentraînement et test A/B, le taux de clics a augmenté de 14 % et l'engagement sur la longue traîne de 23 %.

Mon approche dépend du degré de déséquilibre et du coût business des différents types d'erreurs. Pour un déséquilibre modéré, je commence par ajuster le seuil de décision plutôt que de rééchantillonner, car c'est la façon la plus directe de contrôler le compromis précision-rappel. Pour un déséquilibre plus sévère, j'utilise des poids de classe dans la fonction de perte. Si aucune de ces approches ne fonctionne bien, j'essaie le suréchantillonnage avec SMOTE ou le sous-échantillonnage de la classe majoritaire. J'évalue toujours avec des métriques significatives sous déséquilibre : score F1, AUC précision-rappel, ou coefficient de corrélation de Matthews, plutôt que la précision qui est trompeuse quand les classes sont déséquilibrées. Je vérifie aussi si le déséquilibre dans les données d'entraînement reflète la vraie prévalence en production.

Je surveille trois choses : la qualité des données, le comportement du modèle et l'impact business. La supervision de la qualité des données détecte les violations de schéma, les pics de valeurs nulles et la dérive de distribution des features. La supervision du comportement du modèle suit la distribution des prédictions et les scores de confiance. La supervision de l'impact business relie les sorties du modèle aux résultats qu'il est censé produire. J'utilise des tests statistiques pour la détection de dérive plutôt que des seuils fixes, car les seuils fixes génèrent trop de faux positifs avec des données saisonnières. La plus grande erreur de supervision que je vois est de surveiller les entrées et les sorties mais pas la relation entre elles.

Je commence par le modèle le plus simple qui pourrait fonctionner, puis j'ajoute de la complexité seulement quand les données et le problème le justifient. Pour les données tabulaires avec des features bien conçues, les arbres à gradient boosté sont généralement difficiles à battre et beaucoup plus faciles à déboguer. Pour les données non structurées comme le texte ou les images, les architectures transformer ou CNN pré-entraînées sont presque toujours le bon point de départ. Pour les problèmes de recommandation et de classement, je réfléchis d'abord aux contraintes de service : un modèle complexe qui ne peut pas servir en moins de 50 millisecondes n'est pas viable quelle que soit sa performance hors ligne. La pire décision est de choisir une architecture parce qu'elle est nouvelle, pas parce qu'elle correspond au problème.