Як слід замовити вибір функції та оптимізацію гіперпараметрів у трубопроводі машинного навчання?


15

Моя мета - класифікувати сенсорні сигнали. Поняття мого рішення поки що: i) Інженерні особливості з необробленого сигналу ii) Вибір відповідних функцій за допомогою функції ReliefF та кластеризації підходу iii) Застосування NN, Random Forest та SVM

Однак я захоплений дилемою. У ii) та iii) існують гіперпараметри, такі як k-Найближчі Neigbours для полегшення, або довжина вікна, для якого оцінюється сигнал датчика, або кількість прихованих одиниць у кожному шарі NN

Тут я бачу 3 проблеми: 1) Налаштування параметрів вибору функцій впливатиме на ефективність класифікатора 2) Оптимізація гіперпараметрів класифікатора впливатиме на вибір ознак. 3) Оцінювання кожної можливої ​​комбінації конфігурації непереборне.

Отже, мої запитання: а) Чи можу я зробити спрощене припущення, параметри вибору функції настройки можна від'єднати від налаштування параметрів класифікатора? б) Чи існують інші можливі рішення?


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

1
Конкретний варіант цього питання: Чи повинен вибір функції входити в процедуру перехресної перевірки (як у: # для кожного набору гіперпарам класифікатора: # для кожного перебігу резюме k: 4) передбачити на тестовому наборі?
Nikolas Rieble

1
@NikolasRieble Я щойно написав відповідь на оригінальне запитання, а також включив у відповідь ваше запитання
Денніс Сомерс

Відповіді:


15

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

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

На практиці це може бути насправді неможливо. Загалом, якщо ви не можете дозволити оцінити всі можливі комбінації, рекомендую:

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

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

  3. Оптимізуйте гіперпараметри за допомогою функцій, вибраних на кроці вище. Це має бути хорошим набором функцій зараз, де насправді варто трохи оптимізувати гіперпарами.


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

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

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

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

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

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


1
Чи можете ви також надати посилання?
Nikolas Rieble

1
У цій публікації є кілька знімків відомої книги: nodalpoint.com/not-perform-feature-selection . Вони, схоже, згодні з моїм "можливим рішенням 1". У мене немає обов'язкового посилання на інший випадок, окрім ... самого себе? Я там надав свої міркування / мотивацію, яка, на мій погляд, перевіряється, тож ось довідка: D
Денніс Сомерс

1
Цей розділ ESL повинен бути на 100% необхідним для читання для будь-якого моделюючого прогнозу.
Метью Друрі

Отже, щодо soln 1, як ви отримуєте свій остаточний набір функцій та гіперпараметри моделі після запуску вибору функції (fs) та оптимізації гіперпарами (ho) у кількох ітерах резюме? Окрім того, коли ми виконуємо їх у iter cv, ми спочатку запускаємо fs, а потім ho, використовуючи ці функції?
sma

1
K1

4

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

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

Іншими словами, ви дозволяєте моделі вибирати функції для вас, і ви більш-менш маєте контроль над кількістю функцій. Це насправді скорочує обчислення, оскільки вам більше не потрібно визначати, які функції, а скільки саме функцій і модель робить решту.

Тоді, коли ви робите перехресну перевірку параметра, тоді ви ефективно робите перехресну перевірку і для вибору функції.

Вже є багато моделей ML, які в тій чи іншій мірі включають цю функцію.

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


0

@DennisSoemers має чудове рішення. Я додам два подібних рішення, які є трохи більш чіткими і засновані на інженерії та вибору особливостей: практичний підхід для прогнозних моделей Макса Куна та К'єлла Джонсона.

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

Варіант 1 - вкладений пошук

Якщо обчислювальна потужність не є обмежуючим фактором, рекомендується вкладений підхід для перевірки, в якому є 3 рівні гніздування:

1) зовнішні складки, кожна з яких складається з різного підмножини

2) внутрішні складки, кожна складка з пошуком гіперпараметра

3) внутрішні складки кожного пошукового гіперпараметра, кожна складка з різним набором гіперпараметрів.

Ось алгоритм:

-> Split data into train and test sets.
-> For each external fold of train set:
    -> Select feature subset.
    -> Split into external train and test sets.

    -> For each internal fold of external train set:
        -> Split into internal train and test sets.
        -> Perform hyperparameter tuning on the internal train set. Note that this
           step is another level of nesting in which the internal train set is split
           into multiple folds and different hyperparameter sets are trained and tested on
           different folds.
    -> Examine the performance of the best hyperparameter tuned model 
       from each of the inner test folds. If performance is consistent, redo 
       the internal hyperparameter tuning step on the entire external train set.
    -> Test the model with the best hyperparameter set on the external test set.

-> Choose the feature set with the best external test score.
-> Retrain the model on all of the training data using the best feature set 
   and best hyperparameters for that feature set. 

введіть тут опис зображення Зображення з глави 11.2: Прості фільтри

-> Select feature subsetКрок на увазі бути випадковими, але є й інші методи, які описані в книзі , в розділі 11 .

Щоб уточнити -> Perform hyperparameter tuning step, ви можете прочитати про рекомендований підхід вкладеної перехресної перевірки . Ідея полягає в тому, щоб перевірити надійність тренувального процесу, багаторазово виконуючи процес навчання та тестування на різних складках даних, і переглядаючи середнє значення результатів тесту.

Варіант 2 - окремий пошук гіперпараметра та пошуку функцій

-> Split data into hyperameter_train, feature_selection_train, and test sets.

-> Select a reasonable subset of features using expert knowledge.

-> Perform nested cross validation with the initial features and the 
   hyperparameter_train set to find the best hyperparameters as outlined in option 1.

-> Use the best hyperparameters and the feature_selection_train set to find 
   the best set of features. Again, this process could be nested cross 
   validation or not, depending on the computational cost that it would take 
   and the cost that is tolerable.

Ось як Кун та Джонсон формулюють процес:

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

Глава 12.5: Методи глобального пошуку


-1

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

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


Ви маєте на увазі, що це намагається, поки це не працює: D
Grunwalski

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