Gains :
- Capacité à mettre en place un pipeline de données (collecte, validation, nettoyage, transformation, fractionnement, versionnage) et à placer la validation du schéma au début du pipeline
- Capacité à prendre des décisions concernant les valeurs manquantes et l'étiquetage en fonction de la signification et de la division des champs pour éviter les fuites de données (de groupe et temporelles)
- Possibilité de créer une base de données reproductible en corrigeant la version des données et le caractère aléatoire
La véritable puissance de tout système d’apprentissage automatique réside dans les données et non dans le modèle. Les ingénieurs expérimentés le savent : « les déchets entrent, les déchets sortent » : même le modèle le plus avancé alimenté par de mauvaises données produira de mauvais résultats. Dans cette unité, nous établissons le pipeline de données (pipeline de données : la chaîne d'étapes qui préparent les données brutes pour la formation du modèle) bout à bout et apprenons à quelle étape de cette ligne nous pouvons utiliser en toute sécurité l'intelligence artificielle.
Étapes de la ligne de données
Une ligne de données passe généralement par ces arrêts :
- Collecte (ingestion) : extraction de données à partir de sources (base de données, API, fichiers journaux, flux d'événements).
- Validation : vérifier si les données sont conformes au schéma, aux types et aux plages attendus.
- Nettoyage : gestion des valeurs manquantes, des enregistrements en double, des valeurs aberrantes et des incohérences.
- Transformation : transformer des données brutes en attributs, par exemple convertir une variable catégorielle en nombre, produire un « jour de la semaine » à partir d'une date.
- Fractionnement : séparation en ensembles de formation, de validation et de test.
- Versioning : enregistrement du modèle qui a été entraîné avec quelles données.
L'intelligence artificielle fait gagner du temps en générant des projets de code et des idées, en particulier aux étapes 2, 3 et 4. Mais les décisions telles que l'enregistrement à supprimer, la valeur manquante à remplir et comment, appartiennent à l'ingénieur qui connaît les données ; car un nettoyage inapproprié peut injecter un biais caché dans le modèle.
Vérification des données : défense précoce de la ligne
Les erreurs les plus coûteuses ne commencent pas lors de la production, mais là où l’étape de vérification est ignorée. La validation du schéma vérifie automatiquement si chaque lot de données entrant est conforme à la structure attendue. Par exemple, la colonne âge est-elle comprise entre 0 et 120, le champ email est-il vide, le nombre de colonnes a-t-il changé ?
Astuce : Mettez la vérification au début de la ligne. Plus tôt les données corrompues sont détectées, moins leur réparation coûte cher. Une erreur de schéma détectée lors de la production coûte plusieurs fois plus cher qu’une erreur détectée lors de la phase de formation.
Écrivez un schéma de validation avec pandera (ou grandes attentes) pour le schéma de données suivant. Colonnes et règles :- user_id : entier, ne peut pas être nul, unique- âge : entier, ne peut pas être compris entre 0 et 120- signup_date : date, ne peut pas être dans le futur- pays : catégorique, de l'ensemble {TR, DE, US, UK}- solde : décimal, ne peut pas être négatif Produire un message d'erreur significatif pour chaque violation de règle. Montrez le test avec un exemple de ligne brisée à la fin du code.
Nettoyage : c'est l'humain qui décide
Les valeurs manquantes sont une réalité pour chaque ensemble de données. Façons de gérer :
- Suppression : suppression d'une ligne/colonne avec un taux de manquants très élevé. Mais il existe un risque de perte d’informations et de biais.
- Imputation : imputation avec moyenne, médiane, valeur la plus fréquente ou prédiction basée sur un modèle.
- Drapeau : stockage des informations « manquait » dans une colonne de drapeau distincte – parfois, le manque lui-même est le signal.
La réponse correcte dépend du problème. Dans un ensemble de données médicales, les informations sur la « valeur sanguine non mesurée » doivent être conservées plutôt que supprimées ; Car même le refus du médecin de prendre des mesures est un signal. L'IA peut vous offrir des options et du code ; Vous choisissez celui qui correspond à la réalité du terrain.
Invite faible/Invite forte
Invite faible : « Remplissez les valeurs manquantes. »
Invite forte : "Il y a des valeurs manquantes dans les colonnes suivantes : revenu (12 % manquant, distribution asymétrique à droite), last_login (30 % manquant). Suggérez de remplir le revenu avec la médiane, mais expliquez pourquoi la médiane et non la moyenne. Pour last_login, supposez que la valeur manquante peut être significative (l'utilisateur ne s'est peut-être jamais connecté) ; envisagez de générer un indicateur never_logged_in au lieu de le supprimer. Notez le biais que l'une ou l'autre approche ajouterait au modèle. "
Différence : une invite forte donne des informations sur la distribution et la signification de la zone ; l'intelligence artificielle produit une aide à la décision au lieu d'un remplissage mécanique.
Étiquetage : la qualité se mesure
En apprentissage supervisé (apprentissage dans lequel des exemples sont donnés avec les bonnes réponses), ce que le modèle apprend, ce sont des étiquettes (étiquettes : la bonne réponse pour chaque exemple). La qualité des étiquettes fixe un plafond : si les gens étiquettent de manière incohérente, le modèle apprend de manière incohérente.
L'accord inter-annotateur mesure la vitesse à laquelle différentes personnes attribuent la même étiquette au même échantillon ; Elle s'exprime par un coefficient tel que le Kappa de Cohen. Une faible conformité indique soit que la tâche n’est pas claire, soit que l’instruction est faible.
L'intelligence artificielle aide à l'étiquetage de deux manières : (1) en rédigeant la directive d'annotation, (2) en pré-étiquetant et en demandant à l'humain de le corriger uniquement. Mais le pré-étiquetage avec LLM présente un piège : une erreur systématique du modèle peut s'infiltrer dans l'ensemble du jeu d'étiquettes. C'est pourquoi les humains vérifient toujours certaines étiquettes LLM.
Attention : Ne considérez pas les étiquettes produites par LLM comme une « vérité terrain ». Vérifiez un échantillon avec un humain et mesurez l’ajustement LLM-humain. Si la conformité est faible, le pré-étiquetage fera plus de mal que de bien.
Partition de données : éviter les fuites
L'erreur la plus dangereuse lors de la division des données en formation/validation/test est la fuite de données : le mélange des informations de test dans la formation. Exemples :
- Les enregistrements du même utilisateur relèvent à la fois de la formation et des tests (fuite de groupe).
- Utiliser le futur dans la formation et le passé dans les tests en séries temporelles (fuite temporelle).
- Calcul des paramètres de mise à l'échelle (normalisation) à partir de toutes les données, puis division.
Le fractionnement temporel est essentiel pour les problèmes liés au temps : s'entraîner avec le passé, tester dans le futur. Le fractionnement aléatoire donne un avantage « futur » qui ne se produira jamais en production et gonfle les mesures.
Versionnement et reproductibilité des données
« Avec quelles données avons-nous formé ce modèle ? Être capable de répondre à la question des mois plus tard est la marque d'une ingénierie ML sérieuse. La gestion des versions des données stocke chaque instantané de données avec un ID (hachage ou balise de version). Des outils tels que les données de version DVC (Data Version Control) comme le code.
Pour reproduire le résultat d'un modèle, trois éléments doivent être corrigés : la version des données, la version du code et la graine aléatoire. Il n'est pas possible de dire "j'ai obtenu le même résultat" sans ce trio. Nous approfondirons la reproductibilité dans l'unité 11 ; mais la réparation de la graine dans le pipeline de données commence à partir de là.
trois mini-cases
Cas 1 - La validation du schéma du jour est enregistrée. Lorsqu’une équipe a converti un champ de prix du système en amont de quelques centimes en lires, tous les prix ont chuté 100 fois. La validation du schéma a rejeté le lot car « prix hors plage » et le modèle n'a pas été entraîné avec des données corrompues. Sans vérification, l’erreur ne serait constatée qu’en production, avec des prédictions erronées.
Cas 2 - Biais de remplissage incorrect. Dans un modèle de crédit, les valeurs de revenu manquantes ont été comblées par la moyenne. Mais les revenus manquants concernaient principalement le groupe à faible revenu ; la moyenne a artificiellement « enrichi » ce groupe, et le modèle leur a proposé une limite injustement élevée. Correction du problème avec l'indicateur médiane + absence.
Cas 3 – Fuite temporelle. Un modèle de prévision de la demande avait fière allure sur l'ensemble de test (précision de 95 %), mais s'est écrasé en production. Pourquoi : en raison du fractionnement aléatoire, le modèle avait vu l’avenir. Le passage au regroupement temporel a fait chuter la précision des tests à 78 %, mais il s'agissait d'une véritable performance et l'a maintenue en production.
Modèles copiables
Divisez l'ensemble de données suivant en trois ensembles : formation/validation/test.Contrainte : il s'agit d'une série chronologique ; Utilisez le fractionnement TEMPORAL (s'entraîner dans le passé, tester dans le futur). Empêchez les fuites de lots : ayez le même « customer_id » uniquement dans un cluster. Calculez les paramètres de mise à l'échelle UNIQUEMENT à partir de l'ensemble d'entraînement, puis appliquez-les à tous. Imprimez le nombre de lignes restantes dans le code à chaque étape et ajoutez une assertion qui vérifie l'absence de fuite.
Rédigez un projet de directive d'annotation pour cette tâche d'étiquetage. Tâche : [par ex. Étiqueter les avis clients comme positifs/négatifs/neutres] Clarifier les cas limites : sarcasme, émotion mitigée, comment étiqueter les avis sans rapport avec le produit ? Donnez 5 exemples et 3 cas extrêmes difficiles qui augmenteront la cohérence entre les tagueurs.
Produisez une liste de contrôle de reproductibilité pour ce pipeline de données : - Comment la version des données doit-elle être corrigée ? - Quelles graines aléatoires doivent être définies où ? - Quelles métadonnées (hachage des données, nombre de lignes, date) doivent être enregistrées ? Ma base de code : [langue/bibliothèque]
Vérifiez ce code de nettoyage pour détecter les fuites de données. Regardez plus précisément ceci : les paramètres de mise à l'échelle/d'encodage sont-ils calculés AVANT le fractionnement ? Des statistiques sont-elles calculées à partir de toutes les données ou uniquement de la formation ? Code : [code]
Table de décision : stratégie de valeur manquante
Statut
Approche recommandée
Pourquoi
Distribution numérique asymétrique
remplir avec la médiane
La moyenne est affectée par les valeurs aberrantes
Numérique, symétrique
remplir de moyenne
Protège les informations
La carence peut être importante
Colonne de drapeau + remplissage
Le manque est un signal
Taux manquant > 60%
Colonne évaluer/rejeter
Le bruit est trop
Catégorique
Catégorie "Inconnu"
Ne crée pas de majorité artificielle
Erreurs courantes
- Ignorer la vérification. Sans contrôle de schéma, les données corrompues s’infiltrent silencieusement.
- Mise à l'échelle avant le fractionnement. Il divulgue les statistiques des tests dans l’éducation.
- Utilisation du fractionnement aléatoire dans des séries chronologiques. Il produit de fausses mesures élevées.
- Faire aveuglément confiance aux labels LLM. L’erreur systématique se propage dans les données.
- Ne pas enregistrer la version des données. Vous ne pouvez pas reproduire le résultat.
- Remplissage mécanique avec moyenne. Il ignore la signification du champ et ajoute un biais.
En résumé
Le pipeline de données est le fondement du système ML et mérite plus d'efforts que le modèle. Mettez la vérification en haut ; prendre des décisions de nettoyage et d'étiquetage avec une connaissance du domaine ; éviter les fuites (groupées et temporelles) dans le compartiment ; corrigez la version des données et la graine. L'IA génère du code et des idées sur cette ligne, mais c'est à vous de décider quelles données traiter et comment, car chaque mauvaise décision ici est transmise au modèle comme un défaut caché.
Tâche de candidature
Écrivez un schéma de validation (pandera/Great Expectations) sur votre propre ensemble de données et ajoutez délibérément une mauvaise ligne et montrez qu'elle a été détectée. Divisez ensuite les données de manière temporelle ou par lots, calculez les paramètres de mise à l'échelle à partir de la formation uniquement et vérifiez qu'il n'y a pas de fuite avec une assertion. Écrivez la version des données et le nombre de lignes dans un fichier de métadonnées.
liste de contrôle
- [ ] La validation du schéma s'exécute en haut de la ligne.
- [ ] J'ai choisi la stratégie des valeurs manquantes en fonction de la signification du champ, je ne l'ai pas rempli mécaniquement.
- [ ] J'ai mesuré la qualité des étiquettes (conformité) ; J'ai vérifié humainement les balises LLM.
- [ ] J'ai empêché les fuites de groupe et temporelles dans le volet.
- [ ] Mise à l'échelle/codage calculé à partir de l'ensemble d'apprentissage uniquement.
- [ ] Version des données, nombre de lignes et graines enregistrées.