Як ви використовуєте набір даних 'test' після перехресної перевірки?

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

Скажімо, ми зберегли 20% наших даних у вигляді тестового набору. Потім ми беремо решту, розбиваємо її на k складок і, використовуючи перехресну перевірку, знаходимо модель, яка найкраще прогнозує невідомі дані з цього набору даних. Скажімо, найкраща модель, яку ми знайшли, дає нам 75% точності.

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

Скажімо, ми отримали точність 70% на тестовому наборі даних. То що робити далі? Ми спробуємо іншу модель, а потім іншу, поки не отримаємо високу оцінку на нашому тестовому наборі даних? Але в цьому випадку насправді виглядає так, що ми просто знайдемо модель, яка відповідає нашому обмеженому (лише 20%) тестовому набору . Це не означає, що ми знайдемо модель, яка найкраща в цілому.

Крім того, як ми можемо розглядати цю оцінку як загальну оцінку моделі, якщо вона розраховується лише на обмеженому наборі даних? Якщо цей показник низький, можливо, нам не пощастило і вибрали «погані» дані тесту.

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

Це схоже на інше питання, на яке я відповів стосовно перехресних перевірок та наборів тестів . Основна концепція, яку слід зрозуміти тут, - це незалежні набори даних . Розглянемо лише два сценарії:

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

Тепер, якщо я дослідник, якому не так пощастило, що мені робити? Ну, ви можете спробувати наслідувати саме такий сценарій:

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

Щоб вирішити Ваші інші проблеми:

Скажімо, ми отримали точність набору даних на рівні 70%, тож що робити далі? Ми спробуємо іншу модель, а потім іншу, поки ми не отримаємо високий бал на нашому тестовому наборі даних?

Як-от ідея полягає в тому, що ви створюєте найкращу модель, яку зможете отримати зі своїх даних, а потім оцінюєте її за деякими іншими даними, яких вона ніколи не бачила. Ви можете переоцінити свою схему перехресної перевірки, але, коли у вас є відрегульована модель (тобто гіпер параметри), ви рухаєтесь вперед з цією моделлю, тому що це було найкраще, що ви могли зробити. Головне - НІКОЛИ НЕ ВИКОРИСТОВУВАТИ ДАНІ ТЕСТУВАННЯ ДЛЯ ТУНІнгу . Результатом тестових даних є ефективність вашої моделі щодо "загальних" даних. Повторення цього процесу призвело б до зняття незалежності наборів даних (про що йшла вся суть). Це також стосується іншого питання щодо даних тесту / перевірки .

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

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

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

Однак, як тільки ваші знання про дані змушують вас внести будь-які зміни з оригінальної стратегії, ви вже "підкорили" свій результат. Деякі приклади включають:

• Вибір моделі: ви протестували логістичні, ласо, випадкові лісові, XGBoost та підтримуючі векторні машини та вибрали найкращу модель

• Налаштування параметрів: Ви налаштували XGBoost, щоб знайти оптимальні гіперпараметри

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

• Відсутня імпутація: Ви ввели пропущені змінні із середнім значенням або за допомогою простої моделі на основі інших змінних

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

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

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

https://mlr.mlr-org.com/articles/tutorial/nested_resampling.html

Я припускаю, що ти робиш класифікацію.

Візьміть свої дані та розділіть їх на 70/30 на підмножини TrainingData / testData. Візьміть підмножину TrainingData та розділіть її знову 70/30 на підмножини TrainingData / validateData. Тепер у вас є 3 підмножини вихідних даних - trainingData (.7 * .7), validateData (.7 * .3) та testData (.3).

Ви тренуєте свою модель з TrainingData. Потім ви перевіряєте працездатність цієї моделі за допомогою validateData, яку ми можемо вважати незалежною від trainingData, і тому добре оцінюємо, наскільки добре модель узагальнює. Давайте зробимо вигляд, що ви досягаєте 75% точності.

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

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

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

Навіщо все це робити? Ви намагаєтесь уникнути перевитрати. Завжди є ризик перенастроїти дані, які ви використовуєте, коли ви навчаєтесь і налаштовуєте (він також підтверджує) свою модель. Якщо ви будете тренувати, налаштовувати (перевіряти) та тестувати, використовуючи лише один набір даних, є хороший шанс, що ви перейдете над цими даними, і це не вдасться узагальнити. Розбиваючи набори даних про навчання та тести (і припускаючи, що ви налаштуєтесь за допомогою тестових даних), ви маєте шанс перевірити себе внутрішньо, але все ж є ймовірність, що ви зараз просто перевищуєте дані тесту. Ось чому ми викреслюємо третій набір даних, перевіряємо, тож ми маємо додатковий шар, щоб бути внутрішньо чесними. Налаштування з validateData перешкоджає перероблянню та навчанню даних. Підсумкове тестування з testData не дає можливості перевершити валідацію даних.

Давайте подивимось на це наступним чином

1. Загальна практика

   а) Дані про навчання - використовуються для вибору параметрів моделі.

    i) E.g., finding intercept and slope parameters for an ordinary linear 
       regression model. 
   
    ii) The noise in the training data-set is used in some extent 
        in over-fitting model parameters. 
   

   б) Дані валідації - використовуються для вибору гіпер-параметрів.

    i)  E.g., we may want to test three different models at step 1.a, say 
        linear model with one, two or three variables.   
   
    ii) The validation data-set is independent from training data, and thus, they provide 
        'unbiased' evaluation to the models, which help to decide which 
        hyper-parameter to use. 
   
    iii) We note that, a model trained in 1.a, say y = b_0+b_1*x_1, does 
        not learn anything from this data-set. So, the noise in this data- 
        set is not used to over-fit the parameters (b_0, b_1), but, over- 
        fit exists in choosing which linear model to use (in terms of 
        number of variables). 
   

   c) Дані тестування - використовуються для отримання впевненості у результаті результатів із двох вищеописаних кроків

   i) Used once a model is completely trained
   

2. Ще один спосіб подивитися на частину 1

   а) Наш модельний пул кандидатів - це 5-розмірний набір, тобто

   i) Dimension 1: number of variables to keep in the regression model, 
      e.g., [1, 2, 3].
   
   ii) Dimension 2-5: (b_0, b_1, b_2, b_3). 
   

   б) Крок 1а зменшить кандидатських моделей з 5-ти розмірних до 1-вимірних.

   c) Крок 1b зменшує кандидатів-модель з 1-розмірної до 0-мірної, що є єдиною моделлю.

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

   д) Для роботи з великим розмірним набором моделей з параметрами, гіперпараметрами, типами моделей та методами попередньої обробки будь-яке розбиття на доступні нам дані по суті визначає процес прийняття рішень, який

   i)  Sequentially reducing the model pool to zero-dimension.
   
   ii) Allocating data noise overfitting to different steps of dimension 
       reductions (overfitting the noise in the data is not avoidable but 
       could be allocated smartly). 
   

3. Висновок та відповіді на запитання ОП

   a) Двосплитові (тренування та тестування), трисекційні (тренування, перевірка та тестування) або більша кількість розбиття по суті стосуються зменшення розмірності та розподілу даних (особливо шуму та ризику перенастроювання).

   b) На певному етапі ви можете створити пул кандидатів для остаточної моделі, і тоді ви можете придумати, як спроектувати процес зменшення розмірності послідовно таким чином, щоб

   i) At each step of reducing the dimensions, the output is satisfactory, 
     e.g., not using just 10 data points with large noise to estimate a 
     six-parameter liner model. 
   
   ii) There are enough data for you to reduce the dimension to zero 
      finally. 
   

   в) Що робити, якщо ви не можете досягти b

   i) Use model and data insight to reduce the overall dimensionality of 
     your model pool. E.g., liner regression is sensitive to outliers thus 
     not good for data with many large outliers. 
   
   ii) Choose robust non-parametric models or models with less number of 
      parameter if possible. 
   
   iii) Smartly allocating the data available at each step of reducing the 
       dimensionality. There is some goodness of fit tests to help us decide 
       whether the data we use to train the model is enough or not.