Чи завжди краще використовувати весь набір даних для підготовки кінцевої моделі?

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

Моє запитання: чи завжди це найкраще робити? Що робити, якщо продуктивність насправді погіршиться?

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

Переформулюючи моє початкове запитання:

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

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

ТАКОЖ, ви більше не можете пред'являти претензії до статистичних показників / продуктивності щодо тестових даних, оскільки у вас більше немає набору даних про тест.

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

Але якщо ви знали цільові значення нових даних, чому б ви тренували модель в першу чергу?

Взагалі, я б сказав, якщо у вас є достатня кількість даних з достатньою різноманітністю, тоді перетасовування та розділення даних навчання 80:20: тест повинен бути достатнім для підготовки надійної моделі і не турбуватися про проблеми узагальнення (якщо, звичайно, ви регулюєте модель).

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

Теоретично, чим більше даних побачила ваша розгорнута модель, тим краще слід узагальнити. Отже, якщо ви тренували модель за повним набором наявних у вас даних, вона повинна узагальнити краще, ніж модель, яка бачила, наприклад, набір поїздів / валів (наприклад, ~ 90%) з повного набору даних.

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

[Редагувати]

Ось пов'язане питання з перехресним підтвердженням , де прийнята відповідь робить подібні моменти до мене та згадує інші способи вчинити.

Перебираємо:

1. тренувати модель
2. $\rightarrow$
3. змінити модель
4. перейдіть до кроку 1
5. оцінити продуктивність на тестовому наборі
6. Представлена ​​модель з точністю тесту, знайдена на кроці 5

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

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

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

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

Це потребує певного звикання, але це щось, з чим вам доведеться комфортно. Коли ви кажете "Що робити, якщо продуктивність насправді погіршиться?", Відповідь впевнена, що це може статися. Фактична ефективність може бути гіршою, ніж ви оцінили / прогнозували. Це може бути і краще. І те й інше можливо. Це неминуче. Існує якась притаманна невиправна невизначеність.

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

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

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

Зокрема, стандартна практика така:

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

2. Далі, використовуйте дані тренінгу та валідації, щоб спробувати декілька архітектур та гіперпараметрів, експериментуючи, щоб знайти найкращу модель, яку ви можете. Візьміть 80%, збережені для тренування та валідації, і розділіть його на навчальний набір та набір валідацій, а також тренуйте модель, використовуючи навчальний набір, а потім виміряйте її точність на наборі перевірки. Якщо ви використовуєте перехресну перевірку, ви будете робити це розділення багато разів і середнє значення результатів набір перевірки; якщо ви цього не зробите, ви зробите один розрив (наприклад, 70% / 30% розбиття на 80%, або щось подібне) і оціните ефективність набору для перевірки. Якщо у вас є багато гіперпараметрів, які потрібно спробувати, зробіть це один раз для кожного встановленого параметрами гіперпараметра. Якщо у вас є багато архітектур, які потрібно спробувати, зробіть це для кожної архітектури-кандидата. Ви можете повторити це, використовуючи те, що ви

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

4. Коли ви будете готові, ви тренуєте модель на повному наборі навчання + перевірка (що на 80%), використовуючи архітектуру та гіперпараметри, які ви вибрали раніше. Потім виміряйте його точність на проведеному тестовому наборі. Це ваша оцінка / прогноз щодо того, наскільки точним буде цей підхід моделювання. Ви отримуєте тут єдиний номер. Це число таке, що воно є: якщо ви цим не задоволені, ви не можете повернутися до кроків 1 і 2 і зробити більше експериментів; це було б недійсним.

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

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