Чому лише три перегородки? (навчання, валідація, тест)


61

Коли ви намагаєтесь пристосувати моделі до великого набору даних, загальною порадою є розподіл даних на три частини: навчальний, валідаційний та тестовий набір даних.

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

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

Але чому б не більше розділів? Часто можна розділити гіперпараметри на дві групи та використовувати "валідацію 1", щоб підходити до першої та "валідацію 2", щоб відповідати другій. Або можна навіть трактувати розмір розділених даних тренувань / перевірки як гіперпараметр, який слід настроїти.

Це вже є звичайною практикою в деяких додатках? Чи є якась теоретична робота щодо оптимального розподілу даних?

Відповіді:


79

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

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

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


2
Концептуальна проблема, яку я мав, полягає в тому, що якщо ви порівнюєте достатньо моделей, ви ефективно вписуєтесь у дані валідації, коли ви «приймаєте рішення про переможця», використовуючи дані перевірки. Отже, все ще може бути сенсом розділити дані валідації.
charles.y.zheng

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

2
@ user10882, ваш коментар невірний, як і Firebugs. Як (1) параметри моделі (ваги, пороги), так і (2) так звані "гіпер" параметри (кількість прихованих шарів, кількість дерев рішень) можуть мати сильно різну інтерпретацію та відчуття, але всі лише параметри, що розрізняють різні моделей . Використовуйте дані тренувань, щоб оптимізувати їх усі, використовуйте дані валідації, щоб уникнути переналагодження та перехресну перевірку, щоб забезпечити стабільність результатів. Дані тесту служать лише для визначення очікуваної продуктивності вашої моделі, не використовуйте їх для прийняття / відхилення.
Іцен де Бур

1
@RubenvanBergen: Я розумію, що ви говорите, і це добре і корисно вказати на користувача10882. Але я все ще стверджую, що це в кінцевому рахунку технічність. Скажімо, ви використовуєте алгоритм спуску градієнта, який використовує дані тренувань для висновку напряму кроку (включаючи поліном ступеня ) разом з процедурою перевірки, яка додає втрати валідації до втрати тренінгу на кожному кроці алгоритму спуску градієнта (подібно до раннього зупиняючись). Зараз різниця між "нормальним" або "гіпер" вже не актуальна: це залежить від процедури. n
Іцен де Бур

1
@YtsendeBoer: Досить справедливо - якщо ви використовуєте що-небудь раннє зупинення на основі валідації, тоді я погоджуюся, що межі розмиваються, принаймні з точки зору процедури оптимізації. На мій погляд, це не повністю поєднує поняття "гіперпараметр" з поняттям звичайного. Є ще багато ситуацій, коли до них по-різному ставляться, і я також думаю про них по-різному з точки зору їх ролі у визначенні моделі. У будь-якому випадку, я сподіваюся, що ця дискусія була корисною для інших, щоб проілюструвати (тонкі) відмінності та подібність між цими поняттями =).
Рубен ван Берген

0

Це цікаве питання, і я вважав, що це корисно у відповіді від @Wayne.

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

Зазвичай у нас є два дати: навчання та тестування. Навчальний використовується для пошуку параметрів моделей або для встановлення моделей. Тестовий використовується для оцінки продуктивності моделі за небаченими даними (або реальними даними).

Якщо ми просто зробимо один крок у навчанні, то очевидно, що є процес навчання та тестування (або перевірка).

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.