Quiz 06 – Régression avec Spark ML : pipelines, RMSE et R²

• Jour 2
• 20 questions
• Seuil de réussite : 70 %
• 20 flashcards

Contenus évalués : Estimator et Transformer ; Pipeline, `fit` et `transform`, PipelineModel ; `StringIndexer`, `OneHotEncoder`, `VectorAssembler` et `handleInvalid="keep"` ; colonne `features` attendue par défaut ; filtrage des courses de distance nulle ; découpage train / test 80 / 20 avec `seed=42` et rôle du jeu de test ; `LinearRegression` contre `DecisionTreeRegressor` et palier du forfait JFK ; lecture de `toDebugString` ; comparaison équitable de modèles, `GBTRegressor` et arbre sur la distance seule ; lecture de la RMSE et du R² ; fuites de données avec `total_amount` et la durée de course ; persistance du pipeline entraîné et colonnes attendues par le modèle rechargé.

Une seule bonne réponse par question. Toutes les valeurs citées sont celles des TP de la formation. Le corrigé détaillé s’affiche après la correction. Ce quiz prépare le QCM de validation des acquis du dernier jour.

QCM

Question 1

Dans la préparation du TP 6, tu as utilisé StringIndexer et VectorAssembler. Comment Spark ML classe-t-il ces deux étapes ?

• a) Les deux sont des Transformers.
• b) StringIndexer est un Estimator, VectorAssembler est un Transformer.
• c) StringIndexer est un Transformer, VectorAssembler est un Estimator.
• d) Les deux sont des Estimators.

Question 2

Voici la préparation commune aux deux modèles du TP 6.

preparation = [
    StringIndexer(inputCol="Borough", outputCol="borough_idx", handleInvalid="keep"),
    OneHotEncoder(inputCols=["borough_idx"], outputCols=["borough_vec"]),
    VectorAssembler(inputCols=["trip_distance", "heure", "passenger_count", "borough_vec"],
                    outputCol="features"),
]

Que contient la colonne borough_vec ?

• a) Un vecteur de 0 et de 1 qui indique l'arrondissement de départ.
• b) Un index numérique par arrondissement, calculé à partir du texte de Borough.
• c) Toutes les variables explicatives regroupées dans un seul vecteur.
• d) L'index de l'arrondissement mis à l'échelle, de moyenne nulle et d'écart-type 1.

Question 3

Le TP 6 découpe les données avec df.randomSplit([0.8, 0.2], seed=42). À quoi sert le paramètre seed=42 ?

• a) À garantir que le train contient exactement 80 % des lignes.
• b) À répartir les arrondissements de façon équilibrée entre le train et le test.
• c) À obtenir le même découpage à chaque exécution et pour tous les participants.
• d) À fixer le point de départ de l'entraînement de la régression linéaire.

Question 4

Dans la fonction evaluer du corrigé, tu as écrit ces deux lignes.

model = Pipeline(stages=preparation + [estimateur]).fit(train)
pred = model.transform(test)

Qu'est-ce que model, et que fait la seconde ligne ?

• a) Un Pipeline encore vide d'apprentissage : la seconde ligne l'entraîne sur le test.
• b) Un DataFrame de prédictions sur le train : la seconde ligne y ajoute celles du test.
• c) Un Transformer qui réapprend les catégories et l'arbre sur le test au moment du transform.
• d) Un PipelineModel dont les étapes ont appris sur le train : la seconde ligne applique ces étapes au test et ajoute une colonne prediction.

Question 5

Le StringIndexer du TP 6 est réglé avec handleInvalid="keep". Que se passe-t-il si une valeur de Borough absente du train apparaît dans les données à prédire ?

• a) Le transform échoue avec une erreur sur la valeur inconnue.
• b) La ligne est supprimée silencieusement du résultat.
• c) La valeur reçoit un index supplémentaire, réservé aux catégories inconnues, et la ligne est conservée.
• d) La valeur reçoit l'index de l'arrondissement le plus fréquent dans le train.

Question 6

L'arbre du TP 6 obtient une RMSE de 4,66 $ sur le test. L'objectif du TP était une RMSE inférieure à 5 $. Comment lire ce 4,66 $ ?

• a) Sur des courses jamais vues, l'erreur typique est de 4,66 $, les grosses erreurs pesant plus lourd que les petites.
• b) Le modèle se trompe en moyenne de 4,66 % du montant de la course.
• c) 4,66 % des prédictions du test sont fausses.
• d) Toutes les prédictions du test sont à moins de 4,66 $ du vrai tarif.

Question 7

Un participant calcule la RMSE de son arbre avec model.transform(train) au lieu de model.transform(test). Il obtient une valeur plus basse que sur le test et veut garder celle-ci. Que lui réponds-tu ?

• a) Il a raison : la mesure sur le train porte sur 80 % des données, elle est donc plus fiable.
• b) Cette mesure est trop optimiste : le modèle a déjà vu ces courses. Seul le test mesure l'erreur sur des courses jamais vues.
• c) L'écart montre que seed=42 est mal choisie : il faut changer de graine jusqu'à égaliser les deux RMSE.
• d) L'écart vient de handleInvalid="keep", qui ne s'applique qu'au moment du transform sur le test.

Question 8

Tu sauvegardes puis recharges le meilleur modèle du TP 6.

dt_model.write().overwrite().save("out/modele_montant")
recharge = PipelineModel.load("out/modele_montant")

Qu'est-ce qui a été sauvegardé, et que peux-tu faire de recharge ?

• a) L'arbre seul : il faut refaire un fit du StringIndexer avant d'utiliser recharge.
• b) Les prédictions sur le test, au format Parquet, pour les relire sans recalculer.
• c) Le Pipeline non entraîné : il faut rappeler fit(train) après le chargement.
• d) Tout le pipeline entraîné, des catégories apprises par le StringIndexer jusqu'à l'arbre : recharge.transform s'applique sans réentraînement à de nouvelles courses préparées comme à l'étape 1 (avec heure et Borough), sans encodage manuel.

Question 9

Au TP 6, l'arbre (maxDepth=6) bat la régression linéaire sur le test. En bonus, ajouter RatecodeID (1 = tarif normal, 2 = forfait JFK) aux features de l'arbre divise l'erreur par deux. Quelle explication tient le mieux ?

• a) Un arbre a plus de paramètres qu'une droite, il gagne donc toujours ; RatecodeID n'est qu'une colonne de plus.
• b) Une partie des courses paie un forfait fixe, le palier à 70 $ vu au TP 5 : l'arbre l'approche par découpages, une droite ne le peut pas. RatecodeID donne directement cette information métier.
• c) La régression linéaire échoue faute de StandardScaler sur l'heure ; RatecodeID aide parce qu'il corrige cette différence d'échelle.
• d) RatecodeID est une fuite de données comme total_amount : la RMSE baisse, mais le modèle est inutilisable.

Question 10

Au bonus 3 du TP 6, tu ajoutes total_amount aux features d'une régression linéaire. Le R² monte à 0,98. Quel diagnostic est juste ?

• a) Excellent modèle : un R² aussi proche de 1 justifie de le mettre en production.
• b) Sur-apprentissage : il faut réduire la profondeur du modèle et refaire l'évaluation.
• c) Fuite de données : total_amount contient déjà le tarif et n'est connu qu'après la course. Le R² n'atteint pas 1 car total_amount inclut aussi le pourboire, les taxes et les péages, qui varient.
• d) Fuite de données, et le R² n'atteint pas 1 car le jeu de test, limité à 20 % des courses, est trop petit.

Question 11

Avant tout le reste, le corrigé du TP 6 applique .filter("trip_distance > 0"). Pourquoi ce filtre ?

• a) Pour retirer les courses JFK au forfait, qui faussent la régression linéaire.
• b) Pour retirer les courses courtes, que le tarif minimum rend imprévisibles.
• c) Ces lignes correspondent à des courses annulées ou à des erreurs GPS : les garder apprendrait au modèle des tarifs sans lien avec la distance parcourue.
• d) Parce que la RMSE ne peut pas se calculer quand une feature vaut zéro.

Question 12

Un participant écrit VectorAssembler(..., outputCol="vecteur") et garde le reste du TP 6 à l'identique. Le fit du pipeline échoue : la colonne features est introuvable. Quel diagnostic est juste ?

• a) Les modèles cherchent par défaut une colonne nommée features : il faut garder ce nom, ou indiquer featuresCol="vecteur" au modèle.
• b) VectorAssembler n'accepte pas d'autre nom que features en sortie.
• c) Il faut ajouter un StringIndexer sur la colonne vecteur avant le modèle.
• d) Le nom n'y est pour rien : c'est OneHotEncoder qui doit écrire dans features.

Question 13

Le corrigé affiche le début de l'arbre entraîné avec dt_model.stages[-1].toDebugString. La première règle lue est la suivante.

If (feature 0 <= 5.96)

Comment la lis-tu ?

• a) L'arbre sépare d'abord les courses de l'arrondissement d'index 0 des autres arrondissements.
• b) L'arbre sépare d'abord les courses parties avant 6 h du matin, d'après la colonne heure.
• c) feature 0 désigne la feature la plus importante, numérotée par ordre d'importance après l'entraînement.
• d) feature 0 est trip_distance, première colonne des inputCols du VectorAssembler : l'arbre coupe d'abord les courses à 5,96 miles.

Question 14

Au bonus 1, un arbre entraîné sur la distance seule obtient une RMSE d'environ 4,8 $, contre environ 4,7 $ pour l'arbre du TP. Quelle conclusion en tires-tu ?

• a) L'heure et le nombre de passagers apportent très peu : la distance porte l'essentiel de l'information sur le tarif.
• b) Le modèle complet sur-apprend : il faut garder l'arbre sur la distance seule.
• c) L'écart vient du hasard du découpage : il faut changer de graine avant de conclure quoi que ce soit.
• d) La distance seule ne suffit pas : avec environ 4,8 $, ce modèle rate l'objectif des 5 $.

Question 15

Le bonus 1 évalue aussi GBTRegressor(labelCol="fare_amount", maxIter=20, maxDepth=5). Que fait ce modèle, par rapport à l'arbre unique du TP ?

• a) Il entraîne 20 arbres indépendants en parallèle, qui votent ensemble pour la prédiction finale.
• b) Il entraîne des arbres en série, chacun corrigeant les erreurs du précédent, ce qui rend l'entraînement plus long.
• c) Il réentraîne 20 fois le même arbre sur des découpages différents et garde le meilleur.
• d) Il construit un seul arbre, autorisé à descendre jusqu'à 20 niveaux de profondeur.

Question 16

Pour le bonus 2, un participant ajoute simplement "RatecodeID" aux inputCols du VectorAssembler de la préparation, sans rien changer d'autre. Le fit échoue : colonne RatecodeID introuvable. Pourquoi ?

• a) RatecodeID est une catégorie : elle doit d'abord passer par un StringIndexer.
• b) La colonne RatecodeID n'existe pas dans trips.parquet : il faut la recréer à partir de total_amount.
• c) VectorAssembler refuse les colonnes entières : il faut d'abord convertir RatecodeID en double.
• d) Le select de l'étape 1 n'a gardé que cinq colonnes, et RatecodeID n'en fait pas partie. Le corrigé relit donc le Parquet sans ce select, puis refait le découpage avec seed=42.

Question 17

Dans le corrigé, evaluer construit chaque modèle avec Pipeline(stages=preparation + [estimateur]). Le commentaire précise : « seule la dernière étape change ». Pourquoi est-ce important pour la comparaison ?

• a) Parce que le StringIndexer n'est alors entraîné qu'une fois, puis partagé par les deux modèles.
• b) Parce que LinearRegression et DecisionTreeRegressor exigent exactement les mêmes étapes, sinon le fit échoue.
• c) Parce que les deux modèles voient les mêmes features, le même train et le même test : l'écart de RMSE vient alors du modèle seul.
• d) Parce que le second modèle repart des paramètres appris par le premier, ce qui accélère son entraînement.

Question 18

Pour faire baisser la RMSE, un participant propose d'ajouter la durée de la course, calculée comme tpep_dropoff_datetime moins tpep_pickup_datetime. Que lui réponds-tu ?

• a) Bonne idée : la durée est une information légitime, au même titre que RatecodeID.
• b) Fuite de données : l'heure d'arrivée n'est connue qu'à la fin de la course, donc pas au moment où l'on veut prédire le tarif.
• c) C'est acceptable à condition de normaliser la durée avec un StandardScaler.
• d) Le risque est le sur-apprentissage : il faudra réduire maxDepth après l'ajout.

Question 19

Ton RegressionEvaluator affiche la RMSE et le R² de chaque modèle, sur le même jeu de test. Que mesure le R² ?

• a) La part de la variabilité de fare_amount que le modèle explique sur le test : 1 serait parfait, et la valeur n'a pas d'unité, contrairement à la RMSE en dollars.
• b) Le pourcentage de prédictions exactes au centime près sur le test.
• c) La moyenne des erreurs au carré, exprimée en dollars au carré.
• d) La corrélation entre la distance et le tarif, la même quel que soit le modèle choisi.

Question 20

Le lendemain, tu veux prédire le tarif de nouvelles courses avec le modèle sauvegardé.

recharge = PipelineModel.load("out/modele_montant")
nouvelles = spark.read.parquet("data/trips.parquet")
recharge.transform(nouvelles)

Le transform échoue. Que dois-tu faire ?

• a) Ajouter la colonne fare_amount aux nouvelles courses : le modèle en a besoin pour prédire.
• b) Rappeler fit(nouvelles) sur le modèle rechargé avant le transform.
• c) Calculer toi-même borough_idx et features avant d'appeler transform.
• d) Recréer heure et Borough comme à l'étape 1 (calcul de l'heure, jointure avec les zones) : le pipeline commence au StringIndexer et lit ces colonnes. Aucun réentraînement n'est nécessaire.

Corriger Recommencer

Flashcards

Cliquez sur une carte pour la retourner. Mélangez-les pour une révision active.

Question Estimator ou Transformer : StringIndexer et VectorAssembler ?

◀ Précédente Retourner Suivante ▶ Mélanger 1 / 20