Секвенциальное тестирование: вопросы для собеседования (часть 4)
Подглядывание в результаты теста до его окончания (peeking) завышает вероятность ложноположительного результата. Секвенциальные методы — always-valid p-values, mixture sequential probability ratio test — позволяют проверять результаты в любой момент без инфляции ошибки. На собеседовании это показывает продвинутый уровень кандидата.
Вопросы 16–20 из 20
16Аналитик смотрит промежуточные результаты каждый день, но команда заранее зафиксировала длительность: тест идёт 14 дней, и решение принимают только по финальному анализу в конце. Что наиболее корректно про влияние такого подсматривания на ошибку первого рода для основной проверки?
AОшибка первого рода неизбежно сильно растёт в любом случае, даже если решение принимают только в самом конце эксперимента
BОшибка первого рода не меняется только если отключить рандомизацию и раздать варианты пользователям вручную по списку
CНужно обязательно применять последовательные поправки, даже если досрочная остановка теста никогда не используется командой
DЕсли действительно соблюдён фиксированный горизонт и план эксперимента не меняют по ходу, то контроль ошибки первого рода сохраняется
Ответ: Если решение строго принимают только в конце по заранее заданному горизонту и план не меняют, то формальный контроль ошибки первого рода для основной проверки сохраняется.
Проблема появляется, когда подсматривание влияет на правило остановки или на выбор метрик, сегментов и длительности теста. Если вы просто наблюдаете, но вывод делаете строго по финальной проверке в заранее заданный момент, то обычная интерпретация `p-value` остаётся корректной. На практике стоит учитывать человеческий фактор: промежуточные цифры часто провоцируют необоснованную досрочную остановку.
Подробный разбор → 17Заинтересованные стороны хотят еженедельные апдейты и возможность остановить тест раньше, если уже «всё ясно». Что лучше сделать до запуска?
AСмотреть результаты каждый день и остановить тест, как только впервые станет `p-value < alpha`, без заранее описанных правил последовательного анализа
BЗаранее описать правило остановки, расписание промежуточных проверок и использовать последовательный анализ со схемой расхода значимости `alpha`
CЗапустить один и тот же тест несколько раз подряд на разных неделях и выбрать самый удачный результат для финального отчёта заинтересованным сторонам
DПовысить уровень значимости `alpha` до более мягкого порога, чтобы быстрее получить значимый результат и сократить время до решения о раскатке
Ответ: Если нужны промежуточные решения, заранее задайте правило остановки и используйте корректный последовательный анализ.
Ад-хок остановка по первому `p-value < alpha` превращает процесс в подглядывание и повышает долю ложноположительных результатов. Лучше заранее определить моменты промежуточных проверок и границы для принятия решения. Тогда схема расхода значимости распределит риск ошибки по проверкам, и ранняя остановка будет статистически корректной. Перезапуски того же теста и смягчение `alpha` лишь увеличивают вероятность ложного эффекта без фактического роста качества решений.
Подробный разбор → 18Команда каждый день строит обычный 95% доверительный интервал для разницы метрики и останавливает эксперимент, когда интервал впервые не включает 0. Чем это принципиально отличается от подглядывания по `p-value`?
AЭто полностью безопасно: доверительный интервал и `Type I error` по построению независимы и не страдают от подглядывания
BЭто то же `optional stopping`: для частых проверок нужны последовательные методы, например границы через `alpha spending`
CЭто допустимо только без рандомизации, а с рандомизацией (`A/B`) ежедневная остановка по интервалу запрещена
DЭто увеличивает `power` теста, поэтому проблема ложных срабатываний исчезает сама без дополнительных корректировок
Ответ: Это то же `optional stopping`: ежедневная остановка по обычному 95% интервалу раздувает ошибку I рода, если не использовать последовательные границы.
Если вы проверяете интервал много раз и останавливаетесь, когда он впервые не включает 0, вы делаете несколько попыток найти «значимость». Это раздувает вероятность ошибки I рода точно так же, как подглядывание по `p-value`. Для частых проверок применяют последовательные методы — например, корректные границы через `alpha spending` или групповой последовательный дизайн. Иначе доля ложных находок будет существенно выше заявленных 5%.
Подробный разбор → 19Почему обычный `p-value` становится некорректным, если вы остановили эксперимент «как только `p-value < alpha`»?
AПотому что рандомизация перестаёт работать после первой недели наблюдений и распределение пользователей по группам становится несбалансированным
BПотому что `p-value` рассчитан на фиксированный план, а при остановке по сигналу распределение меняется и растёт ошибка I рода
CПотому что `p-value` нельзя считать до тех пор, пока эксперимент не получил полные 100% запланированного трафика на всех платформах
DПотому что `p-value` равен наблюдаемому приросту метрики, а наблюдаемый прирост естественным образом меняется в каждый день эксперимента
Ответ: Обычный `p-value` рассчитан под фиксированный план; при остановке по сигналу он становится слишком оптимистичным и раздувает ошибку I рода.
Классическая проверка устроена так, что при `H0` вероятность получить `p-value < alpha` равна `alpha`, если проверка делается один раз по плану. Если же вы проверяете много раз и останавливаетесь при первом «успехе», шанс случайно получить значимость растёт. Поэтому нужны методы последовательного тестирования или отказ от остановки по промежуточным значениям `p-value`.
Подробный разбор → 20В эксперименте может вырасти `crash_rate`, поэтому команда хочет иметь возможность остановить тест при ухудшении, не повышая долю ложноположительных по основной метрике. Что лучше сделать?
AОстанавливать тест, как только кому-то из команды показалось, что метрика стала хуже, без формальных критериев, заранее описанной процедуры и без согласования с владельцем эксперимента
BЗаранее задать правило остановки для защитной метрики и использовать корректный подход к промежуточным решениям, например последовательное тестирование с распределением `alpha`
CНе смотреть на `crash_rate` до самого конца эксперимента, чтобы избежать подглядывания, не нарушать стандартную процедуру проверки гипотез и сохранить чистоту анализа
DСразу перевести 100% трафика в тестовую группу, чтобы быстрее понять, что происходит, при необходимости откатить релиз вручную и компенсировать рост ошибок
Ответ: Для ранней остановки по рискам нужно заранее заданное правило остановки и корректный подход к промежуточным решениям.
Если останавливать тест по «ощущениям», вы получите неуправляемое число ложных тревог. Лучше заранее определить, какие защитные метрики мониторим и при каких условиях выключаем тестовую группу. Для основной метрики используйте фиксированный горизонт или распределение `alpha` в последовательном тестировании, чтобы не наращивать ошибку I рода. Полный перевод трафика и игнорирование `crash_rate` лишают команду контроля за рисками.
Подробный разбор →