(Я впевнений, що я написав більшу частину цього вже в якійсь відповіді - але зараз не можу його знайти. Якщо хтось натрапив на цю відповідь, будь ласка, зв’яжіть її). Тут я бачу 2 дещо різні підходи, які, на мою думку, є розумними.
Але спочатку трохи термінології:
- Починаючи з застосованого поля, для мене (готова / підготовлена) модель - готова до використання. Тобто модель містить всю інформацію, необхідну для генерування прогнозів для нових даних. Таким чином, модель містить також гіперпараметри . Як ви побачите, ця точка зору тісно пов'язана із підходом 2 нижче.
- OTOH, алгоритм навчання на моєму досвіді не є чітко визначеним у такому сенсі: щоб отримати (пристосовану) модель, потрібно виконати не лише - так називаємо її "первинну підгонку" - "нормальні" параметри моделі, але також слід зафіксувати гіперпараметри. З моєї точки зору, між параметрами та гіперпарамерами немає великої різниці: обидва є частиною моделі , і їх потрібно оцінювати / вирішувати під час тренінгу.
Я думаю, що різниця між ними пов'язана з різницею між тим, хто розробляє нові алгоритми тренувань, які зазвичай описують клас алгоритмів тренувань разом з деякими рульовими параметрами ( гіперпараметри) які важко / неможливо виправити (або принаймні виправити, як їх слід вирішити / оцінити) без знань про застосування / домен.
Підхід 1: вимагають стабільних результатів оптимізації
При такому підході "тренування моделі" - це відповідність "нормальних" параметрів моделі, і даються гіперпараметри . Внутрішня, наприклад, перехресна валідація, забезпечує оптимізацію гіперпараметра.
Тут вирішальним кроком / припущенням для вирішення дилеми, чий набір гіперпараметрів слід вибрати, є вимагати, щоб оптимізація була стабільною . Перехресне підтвердження для цілей перевірки передбачає, що всі сурогатні моделі достатньо схожі на кінцеву модель (отриману за тим самим алгоритмом тренінгу, який застосовується до всього набору даних), щоб дозволити трактувати їх як рівні (як між собою, так і з кінцевою моделлю). Якщо це припущення руйнується і
Сурогатні моделі все ще однакові (або еквівалентні) між собою, але не до кінцевої моделі, ми говоримо про добре відомий песимістичний ухил перехресної валідації.
Якщо також сурогатні моделі не рівні / еквівалентні одна одній, у нас виникають проблеми з нестабільністю .
Для результатів оптимізації внутрішнього циклу це означає, що якщо оптимізація стабільна, конфлікту у виборі гіперпараметрів немає . І якщо спостерігаються значні зміни в результатах внутрішньої перехресної перевірки, оптимізація не є стабільною . У нестабільних тренувальних ситуаціях є набагато гірші проблеми, ніж просто рішення, який з гіперпараметрів вибрати, і я б дійсно рекомендував відступити в цьому випадку і почати процес моделювання в усьому.
Тут є виняток: хоча в оптимізації може бути кілька локальних мінімумів, що дасть однакові показники для практичних цілей. Вимагати також вибору серед них бути стабільним може бути непотрібною суворою вимогою - але я не знаю, як вийти з цієї дилеми.
Зауважте, що якщо не всі моделі дають однаковий набір виграшних параметрів, тут не слід використовувати оцінки зовнішнього циклу як помилку узагальнення:
- p
- Але якщо не буде прийнято рішення, оскільки всі розбиття дають однакові параметри, це порушить незалежність у зовнішньому циклі: тестові дані кожного розбиття вже ввели рішення, який параметр набору виграє, оскільки він навчав дані у всіх інших розбиттях і таким чином використовувався для оптимізації параметрів.
Підхід 2: розглянути налаштування гіперпараметрів як частину тренінгу з моделями
Такий підхід з'єднує перспективи "розробника алгоритму навчання" та застосованого користувача алгоритму навчання.
Розробник алгоритму навчання забезпечує "голий" алгоритм навчання model = train_naked (trainingdata, hyperparameters). Як потрібен застосований користувач, tunedmodel = train_tuned (trainingdata)який також піклується про фіксацію гіперпараметрів.
train_tunedможе бути реалізовано, наприклад, обернувши оптимізатор на основі крос-валідації навколо голого алгоритму тренувань train_naked.
train_tunedможе бути використаний, як і будь-який інший алгоритм тренінгу, який не потребує введення гіперпараметра, наприклад його вихід tunedmodelможе бути підданий перехресній валідації. Тепер гіперпараметри перевіряються на їх стійкість так само, як і "нормальні" параметри повинні перевірятись на стабільність в рамках оцінки перехресної перевірки.
Це насправді те, що ви робите та оцінюєте в умовах вкладеної перехресної перевірки, якщо ви оцінюєте середню продуктивність всіх виграшних моделей незалежно від їх окремих наборів параметрів.
Яка різниця?
Ми, можливо, закінчимось різними кінцевими моделями, використовуючи ці два підходи:
- остаточна модель у підході 1 буде
train_naked (all data, hyperparameters from optimization)
- тоді як підхід 2 використовує
train_tuned (all data)і - коли це знову запускає оптимізацію гіперпараметрів на більшому наборі даних - це може закінчитися різним набором гіперпараметрів.
Але знову ж застосовується та ж логіка: якщо ми виявимо, що кінцева модель має суттєво різні параметри від супередатних моделей перехресної перевірки, то це симптом припущення 1 порушується. Отже, ІМХО, ми знову не маємо конфлікту, а скоріше перевірки, чи виправдані наші (неявні) припущення. І якщо їх немає, ми все одно не повинні занадто багато ставитись на те, щоб добре оцінити ефективність цієї остаточної моделі.
У мене складається враження (також, побачивши кількість подібних питань / плутанин тут у CV), що багато людей думають про вкладені крос-валідації, які роблять підхід 1. Але помилка узагальнення зазвичай оцінюється відповідно до підходу 2, тому це шлях для фінальна модель також.
Приклад Іриса
Резюме: Оптимізація в основному безглузда. Наявний розмір вибірки не дозволяє розрізняти продуктивність будь-якого з наборів параметрів тут.
Однак, з точки зору програми, висновок полягає в тому, що неважливо, який із 4-х наборів параметрів ви обрали - що не все, що погані новини: ви знайшли порівняно стабільне плато параметрів. Ось тут і перевага належної вкладеної валідації налаштованої моделі: хоча ви не в змозі стверджувати, що це оптимальна модель, ви все ще можете стверджувати, що модель, побудована на всіх даних, використовуючи підхід 2, матиме приблизно 97% точності (95% довірчий інтервал для 145 правильних із 150 тестових випадків: 92 - 99%)
Зауважте, що також підхід 1 не такий вже й далекий, як здається - дивіться нижче: ваша оптимізація випадково пропустила порівняно явного «переможця» через зв’язки (це насправді ще один дуже показовий симптом проблеми розміру вибірки).
Хоча я недостатньо глибоко в SVM, щоб "побачити", що С = 1 повинен бути хорошим вибором тут, я б пішов з більш обмеженим лінійним ядром. Крім того, як ви робили оптимізацію, немає нічого поганого у виборі виграшного набору параметрів, навіть якщо ви знаєте, що всі набори параметрів призводять до практично однакової продуктивності.
Однак у майбутньому врахуйте, чи дає ваш досвід приблизні орієнтовні оцінки, на які показники ви можете розраховувати та приблизно, яка модель буде хорошим вибором. Потім побудуйте цю модель (за допомогою фіксованих вручну гіперпараметрів) та обчисліть довірчий інтервал для її продуктивності. Використовуйте це, щоб вирішити, чи спробна оптимізація взагалі розумна. (Можу додати, що я здебільшого працюю з даними, де отримати ще 10 незалежних випадків непросто - якщо ви знаходитесь у полі з великими незалежними розмірами вибірки, для вас все виглядає набагато краще)
довга версія:
Що стосується прикладів результатів irisнабору даних. irisмає 150 випадків, розглядаються SVM з сіткою 2 х 2 параметрів (2 ядра, 2 порядки для штрафу C).
Внутрішня петля має розколи 129 (2х) та 132 (6х) випадків. Набір параметрів "кращий" не визначається між лінійним або rbf-ядром, обидва з C = 1. Однак внутрішня точність тесту є всіма (включаючи постійно втрачає C = 10) в межах 94 - 98,5% спостережуваної точності. Найбільша різниця у нас в одному з розділів - 3 проти 8 помилок для rbf з C = 1 проти 10.
Ні в чому це суттєва різниця. Я не знаю, як отримати прогнози для окремих випадків у резюме, але навіть припускаючи, що 3 помилки були спільними, а модель C = 10 зробила ще 5 помилок:
> table (rbf1, rbf10)
rbf10
rbf1 correct wrong
correct 124 5
wrong 0 3
> mcnemar.exact(rbf1, rbf10)
Exact McNemar test (with central confidence intervals)
data: rbf1 and rbf10
b = 5, c = 0, p-value = 0.0625
alternative hypothesis: true odds ratio is not equal to 1
Пам’ятайте, що в сітці 2 x 2 є 6 парних порівнянь, тому нам потрібно буде виправити і для кількох порівнянь.
Підхід 1
У 3 з 4 зовнішніх розщеплень, де rbf "переміг" над лінійним ядром, вони насправді мали однакову оціночну точність (я здогадуюсь, що min у випадку зв'язань повертає перший відповідний індекс).
Зміна сітки на
params = {'kernel':['linear', 'rbf'],'C':[1,10]}
врожайність
({'kernel': 'linear', 'C': 1}, 0.95238095238095233, 0.97674418604651159)
({'kernel': 'rbf', 'C': 1}, 0.95238095238095233, 0.98449612403100772)
({'kernel': 'linear', 'C': 1}, 1.0, 0.97727272727272729)
({'kernel': 'linear', 'C': 1}, 0.94444444444444442, 0.98484848484848486)
({'kernel': 'linear', 'C': 1}, 0.94444444444444442, 0.98484848484848486)
({'kernel': 'linear', 'C': 1}, 1.0, 0.98484848484848486)
({'kernel': 'linear', 'C': 1}, 1.0, 0.96212121212121215)
Підхід 2:
Ось clfваша остаточна модель. З random_state = 2, виграє rbf з C = 1:
In [310]: clf.grid_scores_
[...snip warning...]
Out[310]:
[mean: 0.97333, std: 0.00897, params: {'kernel': 'linear', 'C': 1},
mean: 0.98000, std: 0.02773, params: {'kernel': 'rbf', 'C': 1},
mean: 0.96000, std: 0.03202, params: {'kernel': 'linear', 'C': 10},
mean: 0.95333, std: 0.01791, params: {'kernel': 'rbf', 'C': 10}]
(трапляється приблизно 1 в 5 разів, 1 в 6 разів linearі rbfз C = 1прив'язуються до рангу 1)