Gains :
- Capacité à reconnaître différentes sources de données (base de données, API, fichier, web scraping) et les pièges de chacune et à comprendre correctement le schéma
- Capacité à effectuer un échantillonnage reproductible en évaluant si l'échantillon représente la population et le biais de sélection
- Capacité à éliminer les fuites de données au stade de la collecte et à respecter les limites juridiques/éthiques en posant la question « Les aurai-je au moment de la prédiction » dans chaque colonne ?
Chaque analyse est aussi bonne que la qualité des données que vous collectez. Même le modèle le plus avancé au monde produira des résultats peu fiables s’il fonctionne avec des données mal collectées, échantillonnées de manière biaisée ou contenant des informations sur l’avenir. En informatique, ce principe se résume par "garbage in, garbage out" (garbage in, garbage out). Dans cette unité, nous aborderons la phase de collecte de données : comprendre la source, échantillonner, poser des questions de qualité et être attentif au risque de fuite de données dès le premier jour. L’intelligence artificielle est une aide puissante à ce stade ; Écrit une requête SQL, résume le document API, rédige un contrat de données. Mais c’est l’être humain qui décide quelles données vous collectez et si ces données vous représentent.
Connaître les sources de données
Les données proviennent de différents endroits et chaque source comporte ses propres pièges. La base de données (données structurées stockées dans des tables, généralement interrogées avec SQL) est la source la plus courante ; C'est fiable, mais il faut bien comprendre son schéma. L'API (Application Programming Interface) fournit des données en direct mais comporte des risques de limitations de vitesse et de changements de format. Les fichiers (CSV, Excel, JSON) sont flexibles mais sujets à des incohérences de format. Le web scraping est puissant, mais il a des limites juridiques et éthiques ; Tous les sites ne peuvent pas être supprimés.
Attention : Pour le web scraping et la collecte automatique de données, respectez les conditions d'utilisation du site, le fichier robots.txt et KVKK/GDPR. La collecte de données non autorisée entraîne une responsabilité légale. Dans le cadre de la sécurité des informations, utiliser les outils de collecte de données uniquement sur les systèmes pour lesquels vous êtes autorisé et à des fins de défense/analyse ; L’accès non autorisé ou le scraping sont interdits.
Comprendre le schéma : se familiariser avec les données
Avant de collecter un ensemble de données, vous devez comprendre son schéma (les noms des colonnes, leurs types de données, leur signification et leurs relations les unes avec les autres). L'IA est ici très utile pour créer un « dictionnaire de données » – un tableau expliquant la signification de chaque colonne. Mais les explications produites par l’IA sont des prédictions ; Confirmez la véritable signification de chaque colonne avec l’équipe qui a produit les données. Par exemple, une colonne nommée « statut » peut contenir 0/1/2 ; Seule l'équipe d'origine sait s'il s'agit de « en attente/approuvés/annulés » ou autre chose.
Le tableau suivant résume les types de ressources de base et les mises en garde :
Source
point fort
piège
Comment l'IA aide
Base de données SQL
Structurel, fiable
JOIN complexes
Rédige un brouillon de requête
API
données en direct
Limitation de vitesse, changement de forme
Résumés de documents, pull code
CSV/Excel
Souple, rapide
Incohérence du format
Lire/analyser le code
grattage Web
Large portée
Limite légale/éthique
Analyse du brouillon (dans les limites de l'autorité)
Données de journal/événement
détaillé
volume énorme
Requête de filtrage
Illustration : la partie représente-t-elle le tout ?
La plupart du temps, vous travaillez avec un échantillon (un sous-ensemble sélectionné dans la population) plutôt qu'avec l'ensemble des données. La question cruciale est la suivante : cet échantillon représente-t-il la population ? Le biais de sélection est le piège le plus courant. Par exemple, si vous échantillonnez uniquement les utilisateurs de l'application mobile, vous ne verrez pas les utilisateurs Web et vos résultats seront trompeurs. L'échantillonnage aléatoire (chaque enregistrement a une chance égale d'être sélectionné) est le plus sûr dans la plupart des cas ; mais dans les données de séries chronologiques, la répartition se fait de manière chronologique plutôt que aléatoire (nous le verrons dans les unités 7 et 10).
Prise de conscience des fuites dès le premier jour
Les fuites de données sont à l’origine de la plupart des catastrophes et surviennent généralement lors de la phase de collecte des données. Exemple : lors de la prédiction « a-t-il été annulé », si vous ajoutez la colonne « date d'annulation » aux données, le modèle regarde vers le futur. Pendant la phase de collecte, posez une question pour chaque colonne : « Aurai-je réellement cette information au moment où je ferai la prédiction ? Si la réponse est non, cette colonne fuit. Nous aborderons ce sujet en profondeur dans l'unité 10 ; Mais la prise de conscience devrait commencer dès le premier jour.
trois mini-cases
Cas 1 — Le problème de la représentation. Une banque a collecté des données uniquement sur les prêts approuvés pour son modèle de risque de crédit (18 500 enregistrements). Les refus ne figuraient pas dans les données. Le modèle était erroné dans le monde réel car il ne voyait jamais comment les rejets se comporteraient. Leçon : l’échantillon doit être représentatif de l’ensemble de la population à partir de laquelle vous prenez votre décision.
Cas 2 — Changement de forme silencieux. Une équipe extrayait chaque jour des données de prix à partir d’une API. Un jour, le fournisseur d'API a changé la devise de l'USD à l'EUR, mais le nom de domaine est resté le même. Les données ont été collectées dans la mauvaise unité pendant 12 jours ; 3 200 lignes ont été corrompues. Leçon : Vérifiez régulièrement la cohérence du volume et du format des données API.
Cas 3 — Fuite précoce. Un analyste a inclus la colonne « motif de la fermeture du compte » lors de la collecte de données pour une estimation du « taux de désabonnement ». Cette colonne n'a été remplie qu'après le départ du client. Le modèle a donné une précision de 97 % sur l'ensemble de test ; Cela n'a pas fonctionné en production car cette colonne était vide au moment de la prédiction. Leçon : posez à chaque colonne la question « est-ce que je l'ai au moment de la prédiction ?
Quatre modèles copiables
1) Extraction du dictionnaire de données :
Votre rôle : assistant data scientist. Vous trouverez ci-dessous les noms de colonnes et des exemples de valeurs (anonymes) d'une table. Pour chaque colonne, répertoriez sa signification estimée, son type de données et ses risques potentiels en matière de qualité dans un tableau. Marquez les colonnes dont vous n'êtes pas sûr comme « confirmation requise » ; ce qui signifie faire.Colonnes : [coller ici]
2) Code d'échantillonnage (aléatoire, répétable) :
J'ai des pandas df. Écrivez du code qui extrait un échantillon aléatoire représentatif de 5 % à partir de 200 000 lignes. Utilisez random_state=42 (pour la reproductibilité). Ajoutez du code pour vérifier que la distribution des classes de l'échantillon est similaire à celle de la population.
3) Question sur l'analyse des fuites :
Je vais vous donner cette liste de colonnes. Mon objectif est de prédire "est-ce annulé" (0/1). Pour chaque colonne, évaluez si je l'aurai réellement au moment de la prédiction et marquez-la comme "sûr/suspect/fuite". Écrivez votre justification en une phrase. Colonnes : [liste]
4) Projet de requête SQL pull :
J'ai des tables "commandes" et "clients" dans PostgreSQL. Écrivez une requête JOIN qui combine les commandes des 90 derniers jours avec la ville du client et renvoie le montant total et le nombre de commandes par ville. Expliquez le filtre de date et comment les villes NULL sont gérées. Je vais exécuter la requête et la vérifier.
Invite faible/Invite forte
Invite faible :
Tirez-moi un bon exemple de données de cette base de données.
« Bien » est ambigu ; Quel tableau, quelle période, quelle taille, quel but n’est pas clair. L’IA ne produira qu’une requête générique, éventuellement erronée.
Invite puissante :
Votre rôle : Assistant SQL. J'ai une table "transactions": colonnes id, customer_id, date (horodatage), montant (numérique), canal (texte: 'web'/'mobile'). Tâche : rédiger une requête répétable (déterministe avec ORDER BY) qui renvoie 10 000 lignes représentatives de chaque canal pour l'année 2024. Objectif : analyse comparative des canaux. Énumérez les hypothèses de votre requête.
Ici, le tableau, le but, la taille et la répétabilité sont clairs.
Erreurs courantes
- Ne remet pas en cause la représentativité de l’échantillon. Les données facilement accessibles ne sont pas des données exactes ; le biais de sélection fausse le résultat.
- Adaptation des significations des colonnes à l'IA. L'équipe source connaît la signification ; N'utilisez pas la prédiction de l'IA sans la confirmer.
- Ne suit pas le changement de format/d'unité de l'API. Le changement silencieux collecte des données corrompues pendant des jours.
- Ignorer la fuite au stade de la collecte. Si la question « Est-ce que je l'ai au moment de la prédiction » n'est pas posée tôt, le modèle donnera un faux succès.
- Collecte de données non autorisées ou illégales. La violation du fichier robots.txt, des conditions d'utilisation et du KVKK constitue un risque sérieux.
Astuce : conservez une « carte de données » d'une page pour chaque nouvelle source de données : source, date d'extraction, nombre de lignes, limites connues et colonnes présentant un risque de fuite. Cette carte enregistre la question « qu'est-ce que c'était que ces données » et la reproductibilité des mois plus tard.
En résumé
La qualité de l'analyse est limitée par la qualité des données collectées. Bien connaître la source (base de données, API, fichier, scrape) et le schéma ; assurez-vous que l'échantillon est représentatif de la population ; Éliminez les fuites dès le premier jour en demandant à chaque colonne « est-ce que je l'ai au moment de la prédiction ? L’IA est un formidable accélérateur pour le travail de requête et de documentation, mais les humains décident des données à collecter et de leur représentativité. Les limites de l’autorité, de la loi et de la confidentialité passent toujours en premier.
Tâche de candidature
Choisissez une source de données (provenant de votre propre entreprise ou hypothétique). Obtenez une ébauche d'un dictionnaire de données d'IA avec le modèle « extraction de dictionnaire de données » ci-dessus ; Ensuite, évaluez manuellement chaque colonne pour voir si elle a fui. Essayez de trouver au moins une colonne suspecte/fuite et écrivez en une phrase pourquoi c'est risqué.
liste de contrôle
- [ ] Ai-je confirmé la source de données et le schéma avec l'équipe source ?
- [ ] Ai-je vérifié que l'échantillon est représentatif de la population ?
- [ ] Ai-je posé à chaque colonne la question "l'aurai-je au moment du devis ?"
- [ ] Ai-je rendu l'échantillonnage reproductible (graine fixe) ?
- [ ] Ai-je vérifié les limites légales/éthiques (autorité, robots.txt, KVKK) de la collecte ?