GPU для исследований в ML · Криптооплата без KYC
IteraGPU
Метод · Проектирование эксперимента

Абляция должна изолировать одно решение.

Чтобы спланировать абляцию, определите изучаемое изменение, работающий эталон и результат, который изменил бы ваше решение. Сравнивайте варианты на одних и тех же данных оценки, затем изучайте их взаимодействия, прежде чем суммировать выигрыши. Хороший план также предусматривает повторы и подтверждение: проверка множества настроек по одному разу может дать меньше уверенности, чем узкий вопрос, правильно изученный.

01 /

Написание гипотезы, которую можно опровергнуть

«Улучшить модель» не уточняет эксперимент. Напишите вместо этого: «Взвешивание классов улучшает качество на редких классах, не превышая допустимую регрессию на частых классах». Назовите основную метрику, важные подгруппы и порог полезного эффекта. Также зафиксируйте ограничение, остающееся приоритетным: память, время, покрытие входов или простота модели.

Различайте добавление и удаление. Добавление компонента к простому базовому варианту измеряет его вклад в этом контексте. Удаление его из полной системы измеряет то, что теряет эта система. Оба вопроса могут давать разные ответы, когда компоненты взаимодействуют. Поэтому в вашем выводе должны быть указаны базовый вариант и состояние остальных факторов.

Ожидаемый результат — это решение вместе с таблицей вариантов, а не только лучший балл. Прежде чем резервировать вычислительные прогоны, напишите, что заставило бы вас сохранить, отклонить или углубить каждое направление.

Технические источники: NIST — определение цели плана эксперимента

02 /

Построение контрольного варианта и интерпретируемых вариантов

Контрольный вариант повторяет исходную процедуру с её версиями, данными и правилом выбора чекпоинта. Он должен быть воспроизводим в текущей кампании. Старая метрика без предсказаний и полного протокола может служить ориентиром, но она не заменяет этот контрольный вариант автоматически.

Для каждого фактора укажите ровно два сравниваемых состояния. «Аугментация включена» — слишком расплывчато: сохраните преобразование, вероятность и затронутые данные. Опишите параметры, которые остаются общими: предобработка вне изучаемого фактора, разбиения, оптимизатор, бюджет обучения и метод оценки. Если шаги обучения остаются фиксированными, но число обработанных токенов меняется, отметьте это следствие.

Держите финальный тестовый набор вне выбора вариантов. Обученные преобразования и решения по настройке должны использовать данные, предназначенные для этого. Улучшение, полученное после подгонки модели по ошибкам на тесте, уже не является независимой оценкой.

Технические источники: scikit-learn — избегайте утечки данных

03 /

Два фактора требуют четырёх ситуаций

Предположим, вы изучаете 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 — полные факторные планы с двумя уровнями

04 /

Чтение эффектов и их взаимодействия

В этом примере A даёт 1,2 балла без B, но лишь 0,7 балла, когда B уже активен. B даёт 0,8 балла без A и 0,3 балла с A. Совместный выигрыш составляет 1,5 балла, тогда как сумма двух изолированных выигрышей равна 2,0 балла. Разница в −0,5 балла описывает здесь неаддитивное взаимодействие.

Этот расчёт не устанавливает ни его устойчивость, ни объяснение механизма. Он подсказывает, какой вопрос нужно подтвердить: оправдывает ли добавление B к системе, содержащей A, свою сложность всего лишь ради 0,3 балла в этом примере? Изучите также запланированные подгруппы. Одно и то же среднее может скрывать разные выигрыши и потери.

Сравнивайте эти различия на парных повторах, когда это позволяет ваш протокол. Не выбирайте лучший сид для каждого варианта. Если знак или амплитуда сильно меняются от прогона к прогону, решение остаётся неопределённым.

Иллюстративное отклонение от аддитивности = балл(A+B) − балл(A) − балл(B) + балл(контроль) = 71,5 − 71,2 − 70,8 + 70,0 = −0,5 балла.

Технические источники: NIST — комбинации и взаимодействия в факторном плане

05 /

Распределяйте бюджет на важные решения

Объём прогонов — это инструмент планирования, а не прогноз скорости GPU. Пример: у вас есть организационный бюджет в 24 полных прогона. Вы выделяете 12 прогонов на четыре конфигурации по три сида в каждой, 10 на подтверждение контрольного варианта и одного кандидата с пятью новыми сидами и 2 на обоснованные повторы. Итого 24; сколько часов они потребуют, пока неизвестно.

Первые три зёрна/сида служат здесь для исследования, а не для того, чтобы объявить победителя. Зафиксируйте правило выбора кандидата до того, как наблюдать эту серию. Подтверждение использует утверждённый протокол; новые сиды уменьшают зависимость от первоначального выбора, но не исправляют тестовый набор, уже использованный для настройки модели.

Если бюджет не позволяет необходимые повторения, сократите факторы или отложите вопрос. Отдавайте приоритет изменениям, которые влияют на реальное решение: удалить дорогостоящий компонент, устранить сбой или развести два близких варианта. Оставьте время на оценку и артефакты, прежде чем сравнивать тарифы.

Пример распределения бюджета в 24 запуска, без предположений о длительности
ЭтапВычисленияЗапуски
Исследование4 конфигурации × 3 сида12
Подтверждение2 конфигурации × 5 новых сидов10
Документированные повторыРезерв2
Общий бюджет12 + 10 + 224
06 /

Подготовить порядок и правила остановки

Запишите список испытаний до их запуска, с идентификатором, конфигурацией, сидом и приоритетом. Распределите варианты в порядке прохождения, а не так, чтобы сначала завершить все контрольные, а затем все кандидаты. Если период, набор данных или машина образуют блок сравнения, задокументируйте этот блок. Изменение среды в середине серии должно оставаться заметным.

Подготовьте основания для технической остановки, например повторяющиеся ошибки или превышение памяти. Сохраняйте каждую попытку и её статус. Не подменяйте молча сбой более коротким запуском, а неудачное испытание — новым сидом, пока не получите ожидаемый балл.

Досрочная остановка, решённая по баллам, меняет протокол анализа. Если вы планируете промежуточные решения, объявите их правила и их исследовательский характер. Для подтверждающего вывода сохраните план анализа, соответствующий этим решениям.

07 /

Завершить аблацию проверяемым выводом

Итоговая карточка указывает гипотезу, контроль, факторы, повторения, отклонения и случаи сбоя. Свяжите каждое значение с прогнозами и запуском, который его произвёл. Завершите явным решением: компонент сохранён, компонент удалён или данных недостаточно для выбора.

Избегайте трёх упрощений: приписывать изменение фактору A, тогда как предобработка тоже изменилась; складывать отдельные выигрыши, не проверяя их комбинацию; объявлять общее правило на основе единственного корпуса. Аблация устанавливает наблюдение в определённом протоколе. Её охват зависит от данных, модели и фактически изученных вариаций.

Практические вопросы

Нужно ли всегда проверять все комбинации?

Полный план полезен для взаимодействий, но его стоимость растёт с числом факторов. Сначала очертите факторы, которые могут изменить ваше решение. Сокращённый план остаётся возможным, если вы явно укажете эффекты, которые он не позволяет разделить; не представляйте отсутствующие комбинации как проверенные.

Можно ли повторно использовать контроль из предыдущей кампании?

Вы можете повторно его использовать, если данные, код, бюджет, выбор модели и оценка действительно сопоставимы и задокументированы. Иначе проведите контроль заново в текущем протоколе. Различие в версии или разбиении может объяснить отклонение, которое вы хотели приписать компоненту.

Означает ли отрицательный результат, что компонент бесполезен?

Отрицательный результат указывает, что он не даёт искомого эффекта в изученных условиях или что доказательств не хватает. Проверьте неопределённость и взаимодействия, прежде чем обобщать. Документирование этого результата избавляет от повторных затрат бюджета на уже рассмотренное направление.