Сформулюйте гіпотезу, яку можна спростувати
«Покращити модель» не уточнює експеримент. Напишіть натомість: «Зважування класів покращує якість на рідкісних класах, не перевищуючи припустимої регресії на частих класах». Назвіть основну метрику, важливі підгрупи та поріг корисного ефекту. Також зафіксуйте обмеження, яке залишається пріоритетним: пам’ять, час, охоплення входів або простота моделі.
Розрізняйте додавання та вилучення. Додавання компонента до простої базової конфігурації вимірює його внесок у цьому контексті. Вилучення його з повної системи вимірює те, що втрачає ця система. Обидва питання можуть давати різні відповіді, коли компоненти взаємодіють. Тож ваш висновок має уточнювати базову конфігурацію та стан інших факторів.
Очікуваний результат — це рішення разом із таблицею варіантів, а не лише кращий бал. Перш ніж бронювати запуски, запишіть, що змусило б вас зберегти, відкинути чи поглибити кожен напрям.
Технічні джерела: NIST — визначити мету плану експерименту
Побудувати контрольну конфігурацію та інтерпретовані варіанти
Контрольна конфігурація відтворює базову процедуру з її версіями, даними та правилом вибору чекпойнта. Вона має бути виконуваною в поточній кампанії. Давня метрика без прогнозів і повного протоколу може правити за орієнтир, але вона не замінює цю контрольну конфігурацію автоматично.
Для кожного фактора вкажіть точно два порівнювані стани. «Аугментацію увімкнено» — надто розпливчасто: збережіть перетворення, імовірність і відповідні дані. Опишіть параметри, які залишаються спільними: попередня обробка поза досліджуваним фактором, розбиття, оптимізатор, бюджет навчання та метод оцінювання. Якщо кроки навчання залишаються фіксованими, але оброблювані токени змінюються, занотуйте цей наслідок.
Тримайте фінальний тестовий набір поза вибором варіантів. Вивчені перетворення та рішення щодо налаштування мають використовувати дані, призначені для цього. Покращення, отримане після підлаштування моделі на помилках тесту, уже не є незалежним оцінюванням.
Технічні джерела: scikit-learn — уникати витоку даних
Два фактори потребують чотирьох ситуацій
Припустімо, ви досліджуєте A — зважування класів, і B — правило аугментації під час навчання. Щоб побачити їхню взаємодію, розгляньте контрольну конфігурацію, лише A, лише B та A разом із B. Цей план із двома факторами та двома рівнями містить чотири конфігурації. За k бінарних факторів повний план містить 2ᵏ конфігурацій до повторів: кількість запусків зростає швидко.
Наведена далі таблиця — це вигаданий числовий приклад для пояснення ходу думок. Її бали не походять з жодного навчання. Вони представляють вигадані середні macro-F1 за шкалою від 0 до 100; у реальній роботі окремі значення та їхня варіативність залишаються незамінними.
| Конфігурація | A: зважування | B : augmentation | Вигадана macro-F1, зі 100 |
|---|---|---|---|
| Контрольна | Ні | Ні | 70,0 |
| Лише A | Так | Ні | 71,2 |
| Лише B | Ні | Так | 70,8 |
| A + B | Так | Так | 71,5 |
Технічні джерела: NIST — повні факторні плани з двома рівнями
Читати ефекти та їхню взаємодію
У цьому прикладі A дає 1,2 бала без B, але лише 0,7 бала, коли B уже активний. B дає 0,8 бала без A і 0,3 бала з A. Сумарний приріст становить 1,5 бала, тоді як сума двох окремих приростів дорівнює 2,0 бала. Розбіжність у −0,5 бала описує тут неадитивну взаємодію.
Це обчислення не встановлює ні його стійкості, ні пояснення механізму. Воно підказує вам, яке питання підтвердити: чи виправдовує додавання B до системи, що містить A, свою складність лише за 0,3 бала в цьому прикладі? Також розгляньте передбачені підгрупи. Однакове середнє може приховувати різні прирости та втрати.
Порівнюйте ці різниці на парних повторах, коли ваш протокол це дозволяє. Не вибирайте найкращий seed кожного варіанта. Якщо знак або амплітуда сильно змінюються від запуску до запуску, рішення залишається невизначеним.
Технічні джерела: NIST — комбінації та взаємодії у факторному плані
Розподіляти бюджет на важливі рішення
Обсяг запусків — це інструмент планування, а не прогноз швидкості GPU. Приклад: ви маєте організаційний бюджет у 24 повні запуски. Ви відводите 12 запусків на чотири конфігурації по три seed кожна, 10 — на підтвердження контрольної конфігурації та одного кандидата з п'ятьма новими seed, і 2 — на обґрунтовані повтори. Сума дорівнює 24; це ще не говорить про те, скільки годин вони потребують.
Перші три зерна тут слугують для дослідження, а не для визначення переможця. Встановіть правило вибору кандидата до того, як спостерігатимете цю серію. Підтвердження використовує затверджений протокол; нові зерна зменшують залежність від початкового відбору, але не виправляють тестовий набір, який уже використовувався для налаштування моделі.
Якщо бюджет не дозволяє потрібних повторень, зменште фактори або відкладіть питання. Надавайте пріоритет змінам, які впливають на реальне рішення: вилучити дорогий компонент, подолати збій або розділити два близькі варіанти. Залиште час на оцінювання та артефакти, перш ніж порівнювати тарифи.
| Етап | Обчислення | Запуски |
|---|---|---|
| Дослідження | 4 конфігурації × 3 зерна | 12 |
| Підтвердження | 2 конфігурації × 5 нових зерен | 10 |
| Документовані повтори | Резерв | 2 |
| Загальний бюджет | 12 + 10 + 2 | 24 |
Підготувати порядок і правила зупинки
Запишіть перелік спроб до їх запуску, із зазначенням ідентифікатора, конфігурації, зерна та пріоритету. Розподіліть варіанти в порядку проходження замість того, щоб спершу завершити всі контрольні, а потім усі кандидати. Якщо період, набір даних або машина становить блок порівняння, задокументуйте цей блок. Зміна середовища посеред серії має залишатися видимою.
Підготуйте технічні причини зупинки, як-от повторювані помилки або перевищення пам'яті. Зберігайте кожну спробу та її статус. Не замінюйте мовчки збій на коротший запуск, а невдалу спробу — на нове зерно, доки не отримаєте очікуваний результат.
Дострокова зупинка, вирішена на основі результатів, змінює протокол аналізу. Якщо ви плануєте проміжні рішення, оголосіть їхні правила та їхню дослідницьку сферу. Для підтверджувального висновку збережіть план аналізу, придатний для цих рішень.
Завершити абляцію перевірюваним висновком
Підсумкова картка вказує гіпотезу, контроль, фактори, повторення, відхилення та випадки збоїв. Пов'яжіть кожне значення з прогнозами та запуском, який його дав. Завершіть чітким рішенням: компонент збережено, компонент вилучено або даних недостатньо для вибору.
Уникайте трьох спрощень: приписувати зміну A, тоді як попередня обробка також змінилася; додавати окремі виграші без перевірки їхнього поєднання; оголошувати загальне правило на основі одного корпусу. Абляція встановлює спостереження в межах визначеного протоколу. Її сфера залежить від даних, моделі та фактично досліджених варіацій.
Практичні питання
Чи завжди потрібно перевіряти всі комбінації?
Повний план корисний для взаємодій, але його вартість зростає з кількістю факторів. Спершу окресліть фактори, які можуть змінити ваше рішення. Скорочений план залишається можливим, якщо ви поясните ефекти, які він не дозволяє розділити; не подавайте відсутні комбінації як перевірені.
Чи можу я повторно використати контроль з попередньої кампанії?
Ви можете його повторно використати, якщо дані, код, бюджет, відбір моделі та оцінювання справді порівнянні й задокументовані. Інакше повторно запустіть контроль у поточному протоколі. Різниця у версії чи розбитті може пояснити відхилення, яке ви намагалися приписати компоненту.
Чи означає негативний результат, що компонент непотрібний?
Негативний результат вказує, що він не дає шуканого ефекту за досліджених умов або що доказів бракує. Перевірте невизначеність і взаємодії, перш ніж узагальнювати. Документування цього результату дає змогу не витрачати бюджет знову на вже розглянутий напрям.