Travail final

Ce que vous saurez faire

Appliquez chaque module du cours à une nouvelle question. Livrez un jeu de données qu’une autre personne peut vérifier et reconstruire. Vous utilisez la même exportation que dans les leçons, mais le moment de prédiction et la cible sont nouveaux. Vous devez donc reprendre chaque décision au lieu de la copier.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 180 minutes

• Vous avez terminé les modules 1 à 6. Chaque partie ci-dessous indique les leçons qu’elle utilise.
• Votre projet ticket-data fonctionne : larkfield.db, les scripts des modules 3 à 6 et l’environnement virtuel avec pandas 3.0.6. Si quelque chose ne fonctionne pas, exécutez python get_data.py --reset, puis relancez votre pipeline.
• Créez un dossier dans votre projet pour ce travail : reopen/. Placez-y chaque nouvelle requête, chaque nouveau script et chaque rapport du travail.
• Les études de cas du module 7 ne sont pas nécessaires pour ce travail. (Le certificat exige au moins une de ces études.) Pour voir d’abord une démarche semblable sur des données réelles, ouvrez Préparer une table sans fuite pour les demandes de réparation d’une ville. Cette étude définit une cible au moment de prédiction, sépare les données selon le temps et livre un jeu de données avec un contrat.
• Testé avec Python 3.14.6 et pandas 3.0.6 sur macOS.

La question : quels billets reviennent?

Certains billets de soutien sont résolus, puis rouverts : le client écrit de nouveau parce que la réponse n’a pas réglé le problème. Un billet rouvert coûte deux fois à Larkfield. Priya veut entraîner un modèle qui prédit, au moment où un agent résout un billet pour la première fois, si le client le rouvrira dans les 14 jours. Si le modèle signale un billet, l’équipe de Grace peut faire une courte vérification avant de le fermer.

Priya vous demande le jeu de données. Elle vous donne ces faits :

• Moment de prédiction : le premier événement resolved (résolu) du billet dans outcomes.
• Cible : reopened_14d vaut 1 si le billet a un événement reopened (rouvert) dans les 14 jours suivant sa première résolution. Sinon, elle vaut 0.
• Le sondage de satisfaction (csat) est envoyé au client deux jours après une résolution. L’exportation conserve la réponse dans l’événement resolved, mais personne ne la connaît au moment de la résolution.
• Elle veut des données d’entraînement, de validation et de test, séparées selon le temps.

Toutes les données viennent de l’exportation synthétique Larkfield du 1 juillet 2026 à 6 h. Elles ne représentent aucune personne réelle.

Partie 1 : extraire et compter

Utilise Joindre des tables, Des requêtes lisibles, Le temps et le classement et Une extraction reproductible.

1. Écrivez une requête, reopen/01-first-resolution.sql, qui renvoie une ligne par billet ayant au moins un événement resolved. Incluez l’identifiant du billet, le moment de sa première résolution et son resolution_code. Utilisez une fonction de fenêtre et départagez les égalités avec outcome_id.
2. Avant de l’exécuter, prédisez le nombre de lignes. Exécutez-la ensuite et notez le nombre réel.
3. Vérifiez qu’aucun billet n’apparaît deux fois dans le résultat. Écrivez cette vérification sous forme de requête qui doit renvoyer 0 ligne.
4. Écrivez une deuxième requête qui compte les billets sans aucun événement resolved. Expliquez ce que sont ces billets.
5. Vérifiez la concordance : le nombre de billets distincts égale les billets avec une première résolution plus les billets sans résolution. Notez les trois nombres dans votre rapport.
6. Extrayez les données nécessaires au travail avec votre extract.py (ou une copie). Le manifeste doit consigner l’instantané, les paramètres et les nombres de lignes.

Deux comptes, deux étapes

Votre SQL de la partie 1 utilise l’exportation brute, qui contient encore des événements répétés et des lignes de billets en double. La partie 2 les nettoie. Votre rapport doit indiquer l’étape de chaque compte. Le lecteur pourra ainsi suivre les nombres d’une table à l’autre.

Partie 2 : nettoyer et justifier chaque ligne

Utilise Profiler avant de modifier, Transformer avec Python et Traiter les valeurs désordonnées.

1. Exécutez votre étape de nettoyage du module 4 sur les données extraites. Vous pouvez la réutiliser telle quelle.
2. Notez le nombre de lignes d’entrée, les doublons supprimés, les lignes mises en quarantaine (avec chaque raison) et les lignes propres. Les quatre nombres doivent concorder.
3. Profilez les colonnes nouvelles dans ce travail : resolution_code à la première résolution et le délai entre création et première résolution. Cherchez les valeurs manquantes et impossibles (par exemple, une résolution avant la création du billet).
4. Pour chaque problème trouvé, notez une décision : exclure, corriger ou conserver avec un indicateur. Donnez la raison et indiquez où la valeur d’origine est conservée.

Partie 3 : la cible et les caractéristiques au nouveau moment de prédiction

Utilise Caractéristiques et moment de la cible.

C’est la partie la plus importante. Dans le module 5, le moment de prédiction était la création du billet. Maintenant, c’est la première résolution : on en sait plus. Certaines colonnes qui causaient une fuite sont donc maintenant permises. D’autres restent interdites.

1. Calculez reopened_14d pour chaque billet ayant une première résolution.
2. Déterminez quels billets ont une cible définitive. Un billet dont les 14 jours ne sont pas écoulés à l’instantané ne peut pas avoir un 0 définitif. Notez la règle et le nombre de billets qu’elle retire.
3. Faites un tableau de chaque colonne de tickets et de customers, ainsi que de l’information dans outcomes. Pour chacune, écrivez « caractéristique », « pas une caractéristique » ou « caractéristique, avec une modification ». Donnez la raison en une phrase. Portez attention à closed_at, priority_now, first_reply_minutes et csat.
4. first_reply_minutes demande de l’attention. Pour certains billets, la première réponse est arrivée après la première résolution. Déterminez combien. Décidez comment votre caractéristique traite ces billets et expliquez pourquoi.
5. Ajoutez au moins deux caractéristiques qui utilisent le nouveau moment de prédiction. Par exemple, les heures entre création et première résolution, ou « le billet a-t-il été transféré au niveau supérieur avant sa première résolution ». Chacune doit utiliser seulement les événements survenus au plus tard à la première résolution.
6. Construisez la table de modélisation : une ligne par billet, les caractéristiques, la cible, l’identifiant du billet et le moment de résolution pour la séparation.

Partie 4 : une séparation sans fuite

Utilise Choisir une séparation et Ajuster les transformations correctement.

1. Séparez selon le moment de la première résolution : entraînement avant le 1 avril 2026, validation en avril 2026, test dès le 1 mai 2026.
2. Pour chaque partie, notez le nombre de lignes, le nombre de billets rouverts et le taux de réouverture.
3. Expliquez en deux ou trois phrases pourquoi une séparation temporelle convient mieux à cette question qu’une séparation aléatoire.
4. Écrivez un court plan de prétraitement pour Priya. Indiquez les colonnes catégorielles et numériques, le traitement de chaque valeur manquante et les données utilisées pour ajuster chaque transformation. Vous n’entraînez pas de modèle.

Partie 5 : valider et livrer

Utilise Les règles de validation, Suivre la provenance des données et Livrer un jeu de données réutilisable.

1. Écrivez des règles de validation pour les nouvelles tables : colonnes et types requis, valeurs permises, identifiant de billet unique, cible dans {0, 1}, plage attendue du taux de réouverture et aucun moment de caractéristique après la première résolution. Exécutez-les et faites échouer une règle volontairement pour montrer que la vérification fonctionne. Corrigez ensuite les données ou la règle.
2. Écrivez reopen/DATASET.md : source des données, licence, moment de prédiction, cible, étapes dans l’ordre, versions des outils, nombres de lignes à chaque étape et limites connues.
3. Exécutez toute la préparation deux fois à partir d’un instantané propre (python get_data.py --reset). Comparez les sommes de contrôle SHA-256 des fichiers d’entraînement, de validation et de test. Elles doivent être identiques.

Quoi remettre

Un dossier reopen/ avec :

reopen/
  01-first-resolution.sql      and your other queries
  build_reopen.py              (or several scripts) that build the tables from the clean data
  validate_reopen.py           the validation rules
  data/train.csv  valid.csv  test.csv
  MANIFEST.json                row counts, reopen rates and SHA-256 of each file
  DATASET.md                   schema, lineage, decisions and quality report

DATASET.md doit contenir ces sections :

# Reopen dataset (Larkfield, snapshot 2026-07-01)

## Question, prediction time and target
## Source and licence
## Query results and row counts        (Part 1, with the stage of each count)
## Cleaning decisions                   (Part 2: each problem, the decision, the reason)
## Columns: feature or not, and why     (Part 3)
## Split                                (Part 4: rule, counts, rates, preprocessing plan)
## Schema                               (each delivered column: name, type, meaning, allowed values)
## Quality report                       (validation results, known limitations)
## How to rebuild                       (commands, versions, checksums)

Vérifiez votre travail

Ce cours n’a pas encore de personne responsable de la révision. Révisez votre travail avec ce tableau, ou demandez à un collègue de l’utiliser. Marquez chaque élément comme démontré, partiellement démontré ou pas encore démontré, avec une raison. Le cours est terminé quand chaque élément est démontré. Vous pouvez corriger un élément et le réviser aussi souvent que nécessaire.

Preuve requise	Démontré lorsque
Résultats de requêtes et nombres de lignes corrects	La requête de première résolution renvoie une ligne par billet résolu, avec les égalités départagées par outcome_id. Les comptes concordent : billets résolus plus billets jamais résolus égale tous les billets distincts. Chaque compte indique son étape : exportation brute, extraction, données propres ou table de modélisation.
Décisions de nettoyage documentées	Chaque ligne d’entrée est justifiée : propre, mise en quarantaine avec une raison, ou supprimée comme doublon. Les nombres concordent. Chaque correction conserve la valeur d’origine et précise son hypothèse.
Séparation sans fuite	Aucune caractéristique n’utilise d’information obtenue après la première résolution. closed_at, csat et priority_now ne sont pas des caractéristiques, avec une raison correcte pour chacune. first_reply_minutes tient compte des billets dont la réponse est arrivée après la résolution. Les billets dont les 14 jours ne sont pas écoulés sont retirés. La séparation est temporelle et le plan de prétraitement ajuste les transformations seulement sur les données d’entraînement.
Schéma du jeu de données et rapport de qualité	DATASET.md décrit chaque colonne livrée, la provenance des données et les limites. Les règles de validation s’exécutent, une règle qui échoue donne un message clair, et deux exécutions propres donnent les mêmes sommes de contrôle.

Un jeu de données avec des comptes corrects et une caractéristique qui cause une fuite n’est pas complet. Par exemple, si closed_at fait partie des caractéristiques, le troisième élément est pas encore démontré, même si tous les autres nombres sont corrects.

Afficher les nombres clés pour vérifier vos résultats

Ouvrez ceci seulement après avoir obtenu vos propres nombres. De petites différences peuvent venir d’une décision de nettoyage différente, mais documentée. Votre rapport doit alors les expliquer.

• Partie 1 (exportation brute) : 1 403 billets distincts. Dans les données brutes, 1 392 billets ont un événement resolved et 11 n’en ont aucun (ils sont encore ouverts). L’extraction exclut le billet daté de 2036. Le nettoyage met en quarantaine 4 billets, tous résolus. Les données propres contiennent donc 1 387 billets résolus.
• Partie 2 : l’étape de nettoyage du module 4 donne 1 416 → 14 doublons, 4 billets en quarantaine, 1 398 billets propres.
• Partie 3 : 1 387 billets propres ont une première résolution. Parmi eux, 127 ont été résolus moins de 14 jours avant l’instantané (après le 17 juin 2026 à 6 h). Il reste donc 1 260 billets, dont 104 rouverts (8,3 %). Pour les 104 billets rouverts, closed_at diffère de la première résolution. C’est le moment de la dernière résolution : il révèle donc la réponse. Pour 42 billets, la première réponse est arrivée après la première résolution.
• Partie 4 : entraînement, 669 lignes (52 billets rouverts, 7,8 %); validation, 249 (28, 11,2 %); test, 342 (24, 7,0 %).

Assistants d'IA

Vous pouvez demander à un assistant d’IA d’expliquer un message d’erreur ou de proposer une requête. Chaque décision dans DATASET.md doit être la vôtre, et vous devez pouvoir l’expliquer. Vérifiez chaque requête écrite par un assistant en comptant les lignes. Les assistants écrivent souvent des jointures qui semblent correctes, mais multiplient les lignes. Voilà la leçon de ce cours en une phrase.

Erreur courante

La table est propre, les comptes sont corrects et une colonne contient la réponse

Symptôme : toutes les vérifications réussissent. Priya entraîne un premier modèle sur vos données d’entraînement et obtient un score presque parfait sur les données de validation.

Cause : une caractéristique décrit l’avenir du billet. Par exemple, closed_at est le moment de la dernière résolution. Pour un billet rouvert, ce moment vient après la première résolution. Le modèle y lit donc la cible.

Correction : pour chaque caractéristique, demandez-vous : « Au moment de la première résolution, cette valeur est-elle déjà connue et a-t-elle déjà cette valeur? ». Ajoutez une règle de validation : aucun moment de caractéristique ne peut être après resolved_at. Un score trop bon justifie de chercher une fuite avant de célébrer.

Récapitulatif

Dans ce cours, vous avez appris à préparer des données pour l’IA sans erreurs discrètes :

• Structure : ce que représente une ligne, les clés qui relient les tables et comment vérifier que ces clés tiennent.
• SQL : filtres, agrégations et jointures, chacun avec un nombre de lignes qui prouve qu’il a fait ce que vous vouliez.
• Requêtes d’analyse : étapes lisibles, dates, fonctions de fenêtre avec égalités traitées et extractions reproductibles.
• Nettoyage : d’abord un profil, puis exclusion, correction ou imputation, avec les valeurs d’origine conservées et chaque ligne justifiée.
• Modélisation sans risque : caractéristiques connues au moment de prédiction, séparation adaptée à l’utilisation réelle et transformations ajustées seulement sur les données d’entraînement.
• Passation : règles de validation, provenance des données et pipeline qu’une autre personne peut relancer et auquel elle peut se fier.

Gardez votre projet. Apprentissage automatique : du problème à un modèle fiable entraîne et évalue des modèles d’apprentissage automatique sur des données comme celles-ci. Bases de données et stockage pour les applications d’IA traite des bases de données et du stockage pour les applications d’IA.