Прибуток:
- Здатність розпізнавати різні джерела даних (база даних, API, файл, веб-скрейпінг) і підводні камені кожного з них і правильно розуміти схему
- Можливість виконувати повторювану вибірку шляхом оцінки того, чи вибірка представляє сукупність і зміщення відбору
- Здатність усунути витік даних на етапі збору та дотримуватися юридичних/етичних меж, ставлячи запитання «Чи буду я мати це на момент прогнозування» в кожній колонці?
Кожен аналіз настільки хороший, наскільки якісні дані, які ви збираєте. Навіть найдосконаліша модель у світі дасть ненадійні результати, якщо вона працює з даними, які зібрані неправильно, упереджено відібрані або містять інформацію про майбутнє. В інформатиці цей принцип узагальнюється як «сміття всередину, сміття назовні» (garbage in, garbage out). У цьому розділі ми розглянемо етап збору даних: розуміння джерела, вибірка, запитання щодо якості та уважність до ризику витоку даних з першого дня. Штучний інтелект є потужною допомогою на цьому етапі; Пише SQL-запит, підсумовує документ API, проектує договір даних. Але саме людина вирішує, які дані ви збираєте та чи ці дані представляють вас.
Знайомство з джерелами даних
Дані надходять з різних місць, і кожне джерело має свої підводні камені. База даних (структуровані дані, що зберігаються в таблицях, зазвичай запитуються за допомогою SQL) є найпоширенішим джерелом; Він надійний, але необхідно добре розбиратися в його схемі. API (інтерфейс прикладного програмування) надає дані в реальному часі, але несе ризик обмеження швидкості та зміни формату. Файли (CSV, Excel, JSON) гнучкі, але схильні до неузгодженості формату. Веб-збирання є потужним, але воно має юридичні та етичні обмеження; Не кожен сайт можна скинути.
Увага: для веб-збирання та автоматичного збору даних дотримуйтеся умов використання сайту, файлу robots.txt і KVKK/GDPR. Несанкціонований збір даних створює юридичну відповідальність. У контексті інформаційної безпеки використовуйте інструменти збору даних лише в системах, для яких ви авторизовані, і для цілей захисту/аналізу; Несанкціонований доступ або скребки заборонені.
Розуміння схеми: знайомство з даними
Перш ніж збирати набір даних, ви повинні зрозуміти його схему (назви стовпців, їхні типи даних, їх значення та їхні зв’язки один з одним). ШІ дуже корисний тут для створення «словника даних» — таблиці, що пояснює значення кожного стовпця. Але пояснення, які дає AI, є передбаченнями; Підтвердьте справжнє значення кожного стовпця з командою, яка підготувала дані. Наприклад, стовпець із назвою «статус» може містити 0/1/2; Лише вихідна команда знає, чи вони «очікують на розгляд/схвалено/скасовано» чи щось інше.
У наведеній нижче таблиці підсумовано основні типи ресурсів і застереження:
Джерело
сильна сторона
пастка
Як ШІ допомагає
База даних SQL
Конструктивний, надійний
Складні JOIN
Пише чернетку запиту
API
живі дані
Обмеження швидкості, зміна форми
Резюме документів, код вилучення
CSV/Excel
Гнучкий, швидкий
Невідповідність формату
Читання/аналіз коду
веб-збирання
Широкий охоплення
Юридична/етична межа
Розбір чернетки (в межах повноважень)
Дані журналу/події
докладно
величезний обсяг
Фільтрування запиту
Ілюстрація: чи частина представляє ціле?
У більшості випадків ви працюєте з вибіркою (підмножиною, вибраною з сукупності), а не з усіма даними. Важливе питання: чи ця вибірка представляє сукупність? Упередженість відбору – найпоширеніша пастка. Наприклад, якщо ви берете лише вибірку користувачів із мобільного додатка, ви не побачите веб-користувачів, і ваші результати будуть оманливими. Випадкова вибірка (кожен запис має однакові шанси бути відібраним) у більшості випадків є найбезпечнішою; але в даних часових рядів розбиття здійснюється хронологічно, а не випадково (ми побачимо це в розділах 7 і 10).
Витік обізнаності з першого дня
Витік даних є джерелом більшості катастроф і зазвичай виникає на етапі збору даних. Приклад: під час прогнозування «чи було скасовано», якщо ви додаєте стовпець «дата скасування» до даних, модель дивиться в майбутнє. На етапі збору поставте одне запитання для кожного стовпця: «Чи справді я володію цією інформацією, коли буду робити прогноз?» Якщо відповідь «ні», цей стовпець витікає. Ми детально розглянемо цю тему в розділі 10; Але обізнаність повинна починатися з першого дня.
три міні-чохла
Кейс 1 — Проблема репрезентації. Один банк збирав дані лише про схвалені кредити для своєї моделі кредитного ризику (18 500 записів). Відмов у даних не було. Модель помилялася в реальному світі, тому що вона ніколи не бачила, як поводитимуться відмовники. Урок: вибірка має бути репрезентативною для всієї сукупності, з якої ви приймаєте рішення.
Випадок 2 — Тиха зміна форми. Команда щодня отримувала дані про ціни з API. Одного разу постачальник API змінив валюту з доларів США на євро, але ім’я домену залишилося незмінним. Дані збиралися в неправильному підрозділі протягом 12 днів; 3200 рядків було пошкоджено. Урок: регулярно перевіряйте узгодженість обсягу та формату даних API.
Випадок 3 — Ранній витік. Аналітик включив стовпець «причина закриття облікового запису», коли збирав дані для оцінки «відтоку». Ця графа заповнювалася тільки після того, як клієнт пішов. Модель показала 97% точності на тестовому наборі; Це не спрацювало у виробництві, оскільки цей стовпець був порожнім під час передбачення. Урок: поставте в кожній колонці питання "чи є у мене на момент передбачення?"
Чотири шаблони, які можна копіювати
1) Вилучення даних зі словника:
Ваша роль: асистент спеціаліста з обробки даних. Нижче наведено назви стовпців і зразки (анонімних) значень таблиці. Для кожного стовпця вкажіть його приблизне значення, тип даних і потенційні ризики для якості в таблиці. Позначте стовпці, в яких ви не впевнені, як «потрібне підтвердження»; створення сенсу. Стовпці: [вставте сюди]
2) Код вибірки (випадковий, повторюваний):
У мене є панди df. Напишіть код, який виділяє репрезентативну 5% випадкову вибірку з 200 000 рядків. Використовуйте random_state=42 (для відтворюваності). Додайте код, щоб перевірити, чи класовий розподіл вибірки подібний до сукупності.
3) Запитання щодо сканування витоків:
Я дам вам цей список колонок. Моя мета – передбачити, чи скасовано це? (0/1). Для кожного стовпця оцініть, чи справді я матиму його на момент передбачення, і позначте його як «безпечний / підозрілий / витік». Напишіть своє обґрунтування одним реченням. Стовпці: [список]
4) Чернетка запиту на отримання SQL:
У мене є таблиці «замовлення» та «клієнти» в PostgreSQL. Напишіть запит JOIN, який поєднує замовлення за останні 90 днів із містом клієнта та повертає загальну суму та кількість замовлень на місто. Поясніть фільтр дат і як обробляються міста NULL. Я виконаю запит і перевірю його.
Слабка підказка / Сильна підказка
Слабка підказка:
Витягніть мені хороший зразок даних із цієї бази даних.
«Добре» — двозначне; Яка картина, якого періоду, якого розміру, яке призначення – незрозуміло. ШІ створюватиме лише загальний, можливо, неправильний запит.
Потужна підказка:
Ваша роль: SQL-помічник. У мене є таблиця "транзакції": стовпці id, customer_id, date (timestamp), сума (numeric), канал (текст: 'web'/'mobile'). Завдання: написати повторюваний (детермінований із ORDER BY) запит, який повертає 10 000 репрезентативних рядків з кожного каналу за 2024 рік. Мета: порівняльний аналіз каналів. Перелічіть припущення вашого запиту.
Тут таблиця, призначення, розмір і повторюваність зрозумілі.
Поширені помилки
- Не ставлячи під сумнів репрезентативність вибірки. Легкодоступні дані не є точними; зміщення відбору спотворює результат.
- Адаптація значень стовпців до ШІ. Команда джерела знає значення; Не використовуйте передбачення AI без його підтвердження.
- Не відстежується зміна формату/одиниці API. Тиха зміна збирає пошкоджені дані днями.
- Ігнорування витоку на етапі збору. Якщо питання «Чи є у мене це на момент передбачення» не задано раніше, модель дасть помилковий успіх.
- Збір несанкціонованих або незаконних даних. Порушення robots.txt, умов використання та КВКК є серйозним ризиком.
Порада. Зберігайте «картку даних» на одну сторінку для кожного нового джерела даних: джерело, дата отримання, кількість рядків, відомі межі та стовпці, яким загрожує витік. Ця картка зберігає запитання «що це були за дані» та можливість відтворення через кілька місяців.
Підсумовуючи
Якість аналізу обмежується якістю зібраних даних. Добре знати джерело (база даних, API, файл, скачування) і схему; переконайтеся, що вибірка репрезентативна для сукупності; Усуньте витік з першого дня, запитуючи кожен стовпець «чи є у мене це на момент прогнозування?» AI є чудовим прискорювачем для запитів і роботи з документами, але люди вирішують, які дані збирати та їх репрезентативність. Межі повноважень, закон і конфіденційність завжди стоять на першому місці.
Аплікаційне завдання
Виберіть джерело даних (з вашого власного бізнесу чи гіпотетичне). Отримайте чернетку словника даних від ШІ за допомогою шаблону «вилучення словника даних» вище; Потім вручну оцініть кожен стовпець, щоб побачити, чи не стався витік. Спробуйте знайти принаймні одну підозрілу колонку/витік і напишіть одним реченням, чому це ризиковано.
контрольний список
- [ ] Чи підтвердив я джерело даних і схему з командою джерел?
- [ ] Чи перевірив я репрезентативність вибірки для сукупності?
- [ ] Чи поставив я кожній колонці запитання "чи матиму це під час оцінки?"
- [ ] Чи зробив я вибірку повторюваною (фіксоване насіння)?
- [ ] Чи перевірив я юридичні/етичні (орган, robots.txt, KVKK) обмеження збору?