Моделі машинного навчання стають потужнішими щотижня, але найперші моделі та найновіші сучасні моделі мають однакову залежність: якість даних. Максима «сміття всередині – сміття», придумана десятки років тому, продовжує діяти і сьогодні. Нещодавні приклади недоліків перевірки даних безліч, включаючи фіаско JP Morgan / Chase 2013 року та цей чудовий список Excel snafus. Блискучі люди постійно роблять помилки у збиранні та введенні даних, і це не лише наша думка (хоча ми маємо з цим багато особистого досвіду); Каггл провів опитування дослідників даних і виявив, що “брудні дані” є перешкодою номер один для науковців.
Перш ніж створити модель машинного навчання, перед тим як створити інформаційну панель Shiny R, ми оцінюємо набір даних для проекту. Перевірка даних – це складний багатоетапний процес, і, можливо, це не настільки сексуально, як говорити про новітні моделі ML, але ми, як консультанти з питань обробки даних Appsilon, живемо та працюємо над управлінням даними та пропонуємо рішення. І справа не лише у форматі даних. Дані можуть бути пошкоджені на різних рівнях абстракції. Ми можемо розрізнити три рівні:
Структура та формат даних
Правила якісної та ділової логіки
Правила логіки експерта
Рівень перший: структура та формат
Для кожного проекту ми повинні перевірити:
Чи є структура даних послідовною? Даний набір даних повинен мати постійно однакову структуру, оскільки модель ML або програма очікує однаковий формат. Назви стовпців / полів, кількість стовпців / полів, тип даних полів (цілі числа? Рядки?) Повинні залишатися незмінними.
Ми працюємо з кількома наборами даних або об’єднані?
У нас є дублікати записів? Вони мають сенс у цьому контексті чи їх слід вилучити?
Чи є у нас правильні, узгоджені типи даних (наприклад, цілі числа, числа з плаваючою комою, рядки) у всіх записах?
Чи є у нас послідовний формат чисел із плаваючою комою? Ми використовуємо кому або крапку?
Який формат інших типів даних, таких як адреси електронної пошти, дати, поштові індекси, коди країн, і чи узгоджується він?
Це звучить очевидно, але проблеми завжди є, і це потрібно перевіряти щоразу. Потрібно поставити правильні запитання.
Рівень другий: якісні та правила ділової логіки
Ми повинні перевіряти щоразу таке:
Чи завжди параметр ціни (якщо застосовується) невід’ємний? (Ми зупинили кількох наших роздрібних клієнтів рекомендувати неправильні знижки завдяки цьому правилу. Вони заощадили значні суми та запобігли серйозним проблемам завдяки цьому кроку … Докладніше про це пізніше).
Чи є у нас якісь нереальні цінності? Для даних, що стосуються людей, чи завжди вік є реальним числом?
Параметри. Для даних, що стосуються машин, чи завжди параметр стану має правильне значення із визначеного набору? Наприклад лише “ЗАВЕРШЕНО” або “РОБОТА” для стану машини?
Чи можемо ми мати значення «Не застосовується» (NA), нульове чи порожнє значення? Що вони означають?
Чи є у нас кілька значень, що означають одне і те ж? Наприклад, користувачі можуть ввести своє місце проживання різними способами – “НЬЮ-ЙОРК”, “Новий Йорк”, “Нью-Йорк, Нью-Йорк” або просто “Нью-Йорк” для параметра міста. Чи слід їх стандартизувати?
Третій рівень: правила експертів
Правила експертів регулюють щось інше, ніж формат і значення. Вони перевіряють, чи має сенс історія, що лежить за даними. Для цього потрібні знання бізнесу про дані, і відповідальність дослідника даних полягає в тому, щоб бути цікавим, досліджувати та кидати виклик клієнту з правильними питаннями, щоб уникнути логічних проблем з даними. Потрібно поставити правильні запитання.
Експертні правила
Історія no1: чи телепортується ця машина?
Нам було доручено проаналізувати історію машин компанії. Питання полягало в тому, скільки часу працювала кожна машина в певному місці. У нашій базі даних є такі записи:
Ми бачимо, що формат і значення правильні. Але чому машина # 1234 змінювала своє місце розташування щодня? Це можливо? Ми повинні поставити таке питання нашому клієнту. У цьому випадку ми виявили, що фізично не було можливості для машини так часто міняти сайти. Після деякого розслідування ми виявили, що проблема полягала в тому, що програмне забезпечення, встановлене на машині, мало продубльований ідентифікаційний номер, і насправді на різних сайтах було два машини з однаковим ідентифікаційним номером. Дізнавшись, що можливо, ми встановили для цього правила перевірки даних, а потім гарантували, що ця проблема більше не повториться.
Експертні правила можуть бути розроблені лише завдяки тісній співпраці між вченими з даних та бізнесом. Це непроста частина, яку можна автоматизувати за допомогою «засобів очищення даних», які чудово підходять для любителів, але не підходять для чогось віддаленого серйозного.
Історія no2: негативний знак міг змінити всі ціни в магазині
Один з наших роздрібних клієнтів був досить далеко у своєму проектному шляху, коли ми почали працювати з ними. У них вже працював науковий співробітник з питань обробки даних і вже були розроблені власні моделі оптимізації цін. Наша роль полягала у використанні результатів цих моделей та відображенні рекомендацій на інформаційній панелі R Shiny, яка мала використовуватись їх продавцями. Ми мали деякі припущення щодо формату даних, які додаток використовуватиме з їх моделей. Тож ми написали наші правила перевірки того, що, на нашу думку, має очікувати програма, коли зчитує дані.
Ми розсудили, що ціна повинна бути такою:
невід’ємний
ціле число
не повинно бути порожнім значенням або рядком.
в межах розумного діапазону для даного товару
Оскільки ця модель розроблялася протягом декількох тижнів, ми раптом помітили, що ціни повертаються як занадто високі. Це фактично було перевірено автоматично. Це було не так, як ми помітили це у виробництві, ми виявили цю проблему ще до того, як дані навіть потрапили в додаток. Побачивши цей результат у звіті, ми запитали їх команду, чому це сталося. Виявляється, у них був новий розробник, який припустив, що знижки можуть відображатися як від’ємне число, бо чому б і ні? Він не розумів, що деякі програми насправді залежать від цього результату, і припускав, що це буде віднімання значення, а не додавання. Завдяки автоматичній перевірці даних ми могли запобігти помилкам завантаження у виробництво. Ми працювали з їх дослідниками даних, щоб вдосконалити модель. Звичайно, це було дуже швидке виправлення, без зусиль. Але кінцевим результатом було те, що вони заощадили реальні гроші.
Звіт про перевірку даних для всіх зацікавлених сторін
Ось зразок звіту про перевірку даних, який наш робочий процес створює для всіх зацікавлених сторін у проекті:
Намір полягає в тому, щоб звіт про перевірку даних був прочитаний усіма зацікавленими сторонами, а не лише вченими даних та інженерами програмного забезпечення. Після багаторічного досвіду роботи над проектами з обробки даних ми виявили, що багато людей в організації знають реалістичні параметри значень даних, такі як цінові показники. У спільноті зазвичай більше одного експерта, і люди обізнані в різних речах. Нові дані часто додаються з постійною швидкістю, і параметри можуть змінюватися. То чому б не дозволити кільком людям додавати та редагувати правила під час перевірки даних? Тож за допомогою нашого робочого циклу перевірки даних кожен із групи зацікавлених сторін може додавати або редагувати правило перевірки даних.
Наш робочий процес з перевірки даних працює з пакетом assertr (для любителів R). Наш робочий процес запускає правила перевірки автоматично – після кожного оновлення даних. Це точно такий самий процес, як написання модульних тестів для програмного забезпечення. Як і модульне тестування, наш робочий процес перевірки даних дозволяє вам легше виявляти проблеми та виявляти їх раніше; і, звичайно, вирішення проблем на більш ранньому етапі набагато вигідніше.
Нарешті, як виглядають правила перевірки на рівні коду? Ми не можемо показати вам код, створений для клієнтів, тож ось приклад використання даних із системи громадського транспорту міста Варшава (запитується із загальнодоступного API). Скажімо, ми хочемо перевіряти в режимі реального часу розташування та стан усіх транспортних засобів у парку транзитної системи.
У цьому прикладі ми хочемо забезпечити, щоб варшавські автобуси та трамваї працювали в межах міста, тому ми перевіряємо широту та довготу. Якщо транспортний засіб знаходиться за межами міста, то ми, звичайно, хочемо про нього знати! Ми хочемо отримувати оновлення в режимі реального часу, тому ми пишемо правило: „Дані не старші 5 хвилин”. У реальному проекті ми, мабуть, написали б сотні таких правил у партнерстві з клієнтом. Знову ж таки, ми зазвичай запускаємо цей робочий процес ДО того, як ми створимо модель або програмне рішення для клієнта, але, як ви можете бачити з прикладів вище, в запуску робочого циклу перевірки даних навіть величезна цінність! І один із наших клієнтів зауважив, що заощадив більше грошей за допомогою робочого процесу перевірки даних, ніж за допомогою деяких моделей машинного навчання, які раніше були створені для них.
Надання спільного доступу до робочого процесу перевірки даних
Якість даних повинна перевірятися в кожному проекті, щоб отримати найкращі результати. Існує ряд потенційних помилок, які здаються очевидними та спрощеними, але, за нашим досвідом, вони трапляються часто.
Після роботи над численними проектами з компаніями Fortune 500 ми придумали рішення вищезгаданого 3-рівневого кластерного кластера. Оскільки багато людей в організації знають реалістичні параметри для наборів даних, такі як цінові точки, чому б не дозволити кільком людям додавати та редагувати правила під час перевірки даних? Нещодавно ми поділились нашим робочим процесом на хакатоні, спонсорованому Міністерством оцифрування тут, у Польщі. Ми зайняли третє місце у конкурсі, але, що ще важливіше, воно відображає одну з основних цінностей нашої компанії – ділитися нашими передовими практиками з науковою спільнотою даних.
Я сподіваюся, що ви можете розмістити ці висновки у своїй панелі інструментів:
Перевіряйте свої дані рано і часто, охоплюючи всі припущення.
Залучіть фахівця з питань даних на початку процесу
Використовуйте досвід своєї робочої сили у стратегії управління даними
Проблеми з якістю даних надзвичайно поширені
У розпалі проектування нових продуктів, виробництва, маркетингу, планування та реалізації продажів та тисяч інших видів діяльності, що ведуть до успішного бізнесу, компанії іноді забувають про залежності даних та про те, як дрібні помилки можуть мати значний вплив на норму прибутку. Ми розкриваємо ваші знання щодо вашої організації чи бізнесу, ставлячи правильні запитання, а потім навчаємо робочий процес постійно перевіряти його наявність. Ми беремо ваш досвід і використовуємо його неодноразово
Ви можете знайти мене в Twitter за адресою @pawel_appsilon. Прочитайте більше подібних історій у нашому блозі про науку даних та інформаційні панелі R Shiny
Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/how-we-saved-clients-real-money-thanks-data-pawe%C5%82-przytu%C5%82a/.
Paweł Przytuła люб’язно дозволив нам перекласти і опублікувати цю статтю.
Temy.co - Software Development Partner 