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