Проблеми промисловості проти Kaggle. Чи важливіше збирати більше спостережень та мати доступ до більшої кількості змінних, ніж фантазійне моделювання?

Я би сподівався, що назва сама пояснює. У Kaggle більшість переможців використовують укладання з часом сотнями базових моделей, щоб вичавити кілька зайвих% MSE, точність ... Загалом, у вашому досвіді, наскільки важливим є фантазійне моделювання, таке як складання vs просто збір більше даних та більше функцій для даних?

$\times$

Я постійно констатував, що найважливішим є розуміння ваших даних . Якщо ви не розумієте головних водіїв, як Великдень чи акції, ви приречені. Досить часто це зводиться до розуміння конкретного бізнесу досить добре, щоб задати правильні запитання і розповісти відомі невідомі з невідомих .

Після того, як ви зрозумієте свої дані, вам потрібно працювати над тим, щоб отримати чисті дані. Я керував досить великою кількістю юніорів та стажистів, і єдине, чого вони ніколи не відчували у всіх своїх уроках статистики та даних, - це те, наскільки у вас є цілі лайна у ваших даних. Тоді вам потрібно або повернутися до джерела і спробувати отримати його для отримання хороших даних, або спробувати очистити його, або навіть просто викинути якісь речі. Зміна запущеної системи для отримання кращих даних може бути напрочуд важкою.

Після того, як ви зрозумієте свої дані та фактично отримаєте дещо чисті дані, ви можете почати цитувати їх. На жаль, до цього часу я часто опинявся поза часом та ресурсами.

Я особисто є великим шанувальником комбінації моделей ("укладання"), принаймні, в абстрактному розумінні , менш привабливою інженерною технікою, яка часто переходить лінію на надмірну територію - і навіть якщо ваша фантазійна модель в середньому трохи краще, часто виявляється, що справді погані прогнози погіршуються при складнішій моделі. Це зловмисник у моєму бізнесі. Один по-справжньому поганий прогноз може повністю знищити довіру до всієї системи, тому надійність в моєму списку пріоритетів надзвичайно висока. Ваш пробіг може відрізнятися.

На мій досвід, так, комбінація моделей може підвищити точність. Однак дійсно великі вигоди досягаються з перших двох кроків: розуміння ваших даних та їх очищення (або отримання чистих даних в першу чергу).

Я не можу говорити за всю галузь, очевидно, але я працюю в промисловості і змагався на Kaggle, тому я поділюсь моєю POV.

По-перше, ви праві підозрювати, що Kaggle не відповідає точно тому, що люди роблять у галузі. Це гра, за умови ігрового управління, з безліччю шалених обмежень. Наприклад, у змаганнях Сантандера :

1. Імена функцій штучно хешували, щоб приховати своє значення
2. "Навчальний" набір штучно обмежувався меншою кількістю рядків, ніж стовпці, зокрема, щоб техніка вибору, стійкості та регуляризації була б незамінною для успіху.
3. Так званий "тестовий" набір має помітно інший розподіл, ніж навчальний набір, і два, очевидно, не випадкові вибірки з однієї сукупності.

Якби хтось наділив мені такий набір даних на роботі, я б негайно запропонував би попрацювати з ними над функціональною інженерією, щоб ми могли отримати корисніші функції. Я б запропонував використати знання домену для визначення можливих термінів взаємодії, порогів, категорійних стратегій кодування змінної тощо. Підходити до проблеми таким чином явно було б більш продуктивним, ніж намагатися витягнути сенс із вичерпного файлу, створеного інженером бази даних без навчання в МЛ.

Крім того, якщо ви дізнаєтесь, скажімо, що певний числовий стовпчик зовсім не є числовим, а скоріше поштовим індексом, ну ви можете перейти та отримати дані з сторонніх джерел даних, таких як перепис США, щоб збільшити ваші дані. Або якщо у вас є дата, можливо, ви включите ціну закриття S&P 500 на цей день. Такі зовнішні стратегії збільшення вимагають детального знання конкретного набору даних та значних знань про домен, але зазвичай мають набагато більший окуп, ніж чисті алгоритмічні вдосконалення.

Отже, перша велика різниця між індустрією та Kaggle полягає в тому, що в промисловості функції (в сенсі вхідних даних) є оборотними.

Другий клас відмінностей - це продуктивність. Часто моделі будуть розгорнуті для виробництва одним із двох способів: 1) передбачення моделі буде попередньо обчислено для кожного ряду в дуже великій таблиці бази даних, або 2) додаток або веб-сайт передадуть моделі єдиний ряд даних і потрібен прогноз, що повертається в режимі реального часу. Обидва випадки використання вимагають хорошої продуктивності. З цієї причини ви не часто бачите моделі, які можуть повільно передбачати або використовувати величезну кількість пам'яті, наприклад, K-Найближчі-Сусіди або Надвипадкові ліси. Логістична регресія або нейронна мережа, навпаки, можуть набирати партію записів з кількома матричними множеннями, а множення матриць може бути оптимізовано за допомогою правильних бібліотек.Незважаючи на те, що я міг би отримати +0,001 AUC, якби я склав ще одну непараметричну модель, я би цього не зробив, тому що пропускна здатність та затримка прогнозів впаде занадто сильно.

У цьому є і аспект надійності - складання чотирьох різних сучасних сторонніх бібліотек, скажімо, LightGBM , xgboost , catboost і Tensorflow ( звичайно, на GPU ), може призвести до того, що скорочення MSE на .01 виграє змагання в Kaggle, але це чотири різні бібліотеки для встановлення, розгортання та налагодження, якщо щось піде не так. Чудово, якщо ви зможете все це працювати на своєму ноутбуці, але запустити його в контейнер Docker, що працює на AWS, - зовсім інша історія. Більшість компаній не хочуть виступати перед невеликою командою девес, аби вирішувати подібні проблеми розгортання.

Але це означає, що укладання в собі не обов'язково є величезною справою. Насправді, укладання декількох різних моделей, які працюють однаково добре, але мають дуже різні межі прийняття рішень, - це чудовий спосіб отримати невеликий удар в AUC і великий удар в надійності. Просто не закидайте стільки кухонних мийок у ваш неоднорідний ансамбль, що у вас починають виникати проблеми з розгортанням.

З мого досвіду, більше даних і більше функцій важливіше, ніж найпопулярніша, найзградженіша, найбільш налаштована, модель, яку можна придумати.

Подивіться змагання з реклами в Інтернеті, що відбулися. Моделі виграшів були настільки складними, що вони закінчили цілий тиждень, щоб потренуватися (за дуже невеликим набором даних, порівняно з галузевим стандартом). Крім того, прогнозування в складеній моделі довше, ніж у простої лінійної моделі. З тієї ж теми пам’ятайте, що Netflix ніколи не використовував свій алгоритм 1M $ через інженерні витрати .

Я б сказав, що олімпіади з інформатики в Інтернеті - це хороший спосіб, щоб компанія знала, "яка найвища точність (або будь-яка метрика ефективності), яку можна досягти", використовуючи дані, які вони збирають (у певний момент часу). Зауважте, що це насправді є важка проблема, яка вирішується! Але, в галузі, знання на місцях, апаратні та ділові обмеження зазвичай відштовхують від використання "фантазійного моделювання".

Укладання значно збільшує складність і зменшує інтерпретаційність. Вигоди, як правило, порівняно невеликі, щоб виправдати це. Тому, хоча демонтаж, ймовірно, широко застосовується (наприклад, XGBoost), я думаю, що укладання є досить рідкою у промисловості.

На мій досвід, збирання хороших даних та можливостей набагато важливіше.

Клієнти, з якими ми працювали, зазвичай мають багато даних, і не всі вони у форматі, який можна легко експортувати або легко працювати. Перша партія даних зазвичай не дуже корисна; наше завдання працювати з клієнтом, щоб зрозуміти, які дані нам знадобляться, щоб зробити модель більш корисною. Це дуже ітеративний процес.

Триває багато експериментів, і нам потрібні моделі, які:

1. Швидко тренуватися
2. Швидко передбачити (Також часто це вимога бізнесу)
3. Легко інтерпретувати

Пункт 3) особливо важливий, тому що моделі, які легко інтерпретувати, простіше спілкуватися з клієнтом, і їх легше зловити, якщо ми щось зробили не так.

Ось те, що на Kaggle не приходить багато: the

• більше змінних у вашій моделі та
• чим складніший зв'язок між цими змінними та результатом,

тим більше ризику ви зіткнетеся протягом життя цієї моделі. Час, як правило, або заморожений у змаганнях з Kaggle, або є коротке вікно майбутнього часу, де надходять значення тестових наборів. У промисловості ця модель може працювати протягом років. І все, що може знадобитися, це одна змінна перейти сірий провід, щоб вся ваша модель пішла в пекло, навіть якщо вона була побудована бездоганно. Я розумію, що ніхто не хоче дивитись конкурс, де конкуренти ретельно врівноважують складність моделі з ризиком, але там, де на роботі, ваш бізнес та якість життя постраждають, якщо щось не піде не так з моделлю, якою ви керуєте. Навіть надзвичайно розумні люди не застраховані. Візьмемо, наприклад, збій прогнозування Google грипу . Світ змінився, і вони не побачили, що він прийде.

На запитання ОП: " Взагалі, з вашого досвіду, наскільки важливим є фантазійне моделювання, таке як складання vs просто збір більшої кількості даних та додаткових функцій для даних? " Ну, я офіційно старий, але моя відповідь полягає в тому, що якщо у вас немає дійсно міцна інфраструктура моделювання, краще мати прості моделі з мінімальним набором змінних, де співвідношення введення-виведення є відносно простим. Якщо змінна ледь покращує показник збитків, залиште це. Пам'ятайте, що це робота. Отримайте ваші удари поза роботою на конкурсах Kaggle, де є стимул "йдіть великим чи йдіть додому".

Одним винятком буде, якщо бізнес-ситуація вимагає певного рівня продуктивності моделі, наприклад, якщо вашій компанії потрібно було досягти переваги або перемогти результати конкурента, щоб отримати певну перевагу (можливо, в маркетингу). Але коли існує лінійна залежність між продуктивністю моделі та виграшем бізнесу, збільшення складності, як правило, не виправдовує фінансовий прибуток (див. " Netflix ніколи не використовував свій алгоритм на 1 мільйон доларів за рахунок інженерних витрат " - вибачте @ RUser4512 за посилання на ту саму стаття). Однак у змаганнях Kaggle цей додатковий виграш може перенести вас на сотні рангів, коли ви проходите рішення, що перебувають поблизу.

Коротка відповідь - цитата, яка мені подобається з книги Гері Каспарова «Глибоке мислення»

Розумний процес перемагає чудові знання та досконалі технології

Я працюю в основному з фінансовими даними часових рядів, і над тим, щоб збирати дані, очищати їх, обробляти їх, а потім працюю з власниками проблем, щоб з'ясувати, що вони насправді хочуть зробити, щоб потім створити функції та моделі, щоб їх спробувати вирішити. проблема і, нарешті, ретроспективно вивчити процес, який слід покращити в наступний раз

Весь цей процес більший, ніж сума його частин. Я схильний отримувати "прийнятну" ефективність узагальнення з лінійною / логістичною регресією та спілкуючись з експертами по домену, щоб генерувати функції, набагато краще витрачений час, ніж витрачати час над пристосуванням моєї моделі до даних, які я маю.