Professional Machine Learning Engineer — Questions d'entraînement et examen blanc

Les méthodes de tokenisation en sous-mots comme SentencePiece et WordPiece sont la norme en NLP moderne. TensorFlow Text implémente trois tokenizers de sous-mots : BertTokenizer (qui utilise WordPiece, comme dans BERT), WordpieceTokenizer et SentencepieceTokenizer (utilisé par T5 et mT5). La tokenisation en sous-mots découpe les mots en unités porteuses de sens (par exemple, 'searchability' → 'search ##ability') et gère élégamment les mots hors vocabulaire tout en gardant une taille de vocabulaire raisonnable (30K-100K tokens). WordPiece s'appuie sur un algorithme glouton qui privilégie la correspondance la plus longue ; SentencePiece est indépendant de la langue et traite du texte brut sans pré-tokenisation. La tokenisation au niveau du mot échoue sur les mots jamais vus. Celle au niveau du caractère produit des séquences excessivement longues. La tokenisation à base de règles ne se généralise pas à des langues variées. Les modèles Gemini et PaLM de Google utilisent SentencePiece. Astuce d'examen : tokenisation NLP moderne = sous-mots (SentencePiece/WordPiece/BPE). Ref: www.tensorflow.org/text/guide/subwords_tokenizer

Gemini Enterprise Agent Platform ML Metadata capture les métadonnées des pipelines de ML sous forme de graphe, avec trois types d'entités : les artefacts (jeux de données, modèles, métriques), les exécutions (étapes du pipeline) et les contextes (exécutions de pipeline), reliés par des événements. On obtient ainsi un graphe de traçabilité interrogeable qui répond à des questions comme : « Quel jeu de données a servi à entraîner ce modèle ? » et « Quels hyperparamètres ont produit le modèle le plus précis ? » ML Metadata est toujours actif : il enregistre automatiquement tous les artefacts d'entrée et de sortie de chaque exécution de pipeline. Experiments on Agent Platform suit les paramètres et les métriques pour comparer des expérimentations, mais n'offre pas de traçabilité complète au niveau du pipeline. Cloud Audit Logs enregistre les appels d'API à des fins de sécurité, pas les relations entre artefacts de ML. Model Registry gère les versions de modèles mais ne remonte pas jusqu'aux jeux de données. Astuce d'examen : « lineage » ou « provenance » dans les pipelines de ML → Gemini Enterprise Agent Platform ML Metadata. Ref: docs.cloud.google.com/vertex-ai/docs/ml-metadata/introduction

Le skew entre entraînement et serving au niveau des features vient souvent du fait que les pipelines de calcul par lots et en streaming utilisent un code différent. Feature Store stocke et sert fidèlement les valeurs qu'on y écrit : si le pipeline par lots calcule une feature avec une certaine agrégation ou normalisation et que le pipeline en streaming utilise une autre implémentation, le modèle reçoit au moment du serving des valeurs de features différentes de celles de l'entraînement. La documentation de Google le note : « Sans featurestore, tu peux te retrouver avec des chemins de code différents pour générer les features entre l'entraînement et le serving. » La solution est de partager la logique de calcul, idéalement avec Apache Beam, qui prend en charge les modes par lots et streaming. Feature Store ne restreint pas l'ingestion mixte, et sa couche de serving fonctionne correctement. Le surapprentissage est un problème de modèle, pas de pipeline de features. Astuce d'examen : des valeurs de features différentes en ligne et à l'entraînement → vérifie la parité de la logique de calcul. Ref: docs.cloud.google.com/vertex-ai/docs/featurestore/overview

BigQuery ML te permet de construire des modèles en SQL, directement là où les données résident. Pour de la classification tabulaire comme la prédiction d'attrition, BOOSTED_TREE_CLASSIFIER (propulsé par XGBoost) est efficace et demande très peu de code : une seule instruction CREATE MODEL. Les données ne quittent jamais BigQuery, ce qui supprime la complexité des pipelines. BigQuery ML prend en charge la régression linéaire et logistique, k-means, ARIMA_PLUS, les arbres boostés, les DNN et la factorisation matricielle. Exporter vers Cloud Storage pour un entraînement TensorFlow personnalisé ajoute une charge d'infrastructure inutile. AutoML Tables impose d'exporter les données. Les modèles pré-entraînés de Model Garden visent les données non structurées (texte, images), pas les données tabulaires structurées. Astuce d'examen : données structurées/tabulaires déjà dans BigQuery + peu de code → BigQuery ML. Ref: docs.cloud.google.com/bigquery/docs/reference/standard-sql/bigqueryml-syntax-create-boosted-tree