Секвенциальное тестирование: вопросы для собеседования (часть 3)
Подглядывание в результаты теста до его окончания (peeking) завышает вероятность ложноположительного результата. Секвенциальные методы — always-valid p-values, mixture sequential probability ratio test — позволяют проверять результаты в любой момент без инфляции ошибки. На собеседовании это показывает продвинутый уровень кандидата.
Вопросы 11–15 из 20
11В чём ключевое отличие «просто `peeking` в дашборд» от корректного `sequential testing`?
A`Sequential testing` запрещает смотреть результаты до конца, а `peeking` разрешает
B`Sequential testing` заранее задаёт `stopping rule` и границы (например, через `alpha spending`), а `peeking` обычно не имеет корректных правил остановки
C`Peeking` требует больше трафика, чем `sequential testing`, поэтому он хуже
D`Sequential testing` работает только без `randomization`, иначе он не нужен
Ответ: В `sequential testing` заранее фиксируют `interim analysis`, `stopping rule` и распределение `alpha`; при обычном `peeking` этих правил нет.
В `sequential testing` заранее фиксируют моменты `interim analysis`, критерии остановки и то, как расходуется `alpha`. Благодаря этому сохраняется контроль `Type I error`. При обычном `peeking` команда часто останавливается при первом «значимом» дне, что превращается в `optional stopping`.
12Что обязательно зафиксировать до старта, если вы допускаете раннюю остановку в рамках `sequential testing`?
AЦвет графиков в дашборде и частоту созвонов команды
BИмена владельцев метрик и стиль презентации результата
C`Stopping rule`, расписание `interim analysis`, основную метрику и уровень `alpha`.
DЗначение будущего `lift`, чтобы потом сравнить с фактом
Ответ: Для корректного `sequential testing` нужно заранее зафиксировать `stopping rule`, точки `interim analysis` и целевую метрику с уровнем `alpha`.
Когда план фиксируется до запуска, вы не подгоняете правила под шум. Это защищает от `peeking` в стиле «остановили, как только стало значимо». Кроме того, заранее понятно, как интерпретировать `p-value` и как распределяется `alpha` через `alpha spending`.
13В эксперименте вы делали ежедневные проверки. На 3-й день получили `p-value < alpha` и остановили тест, но позже выяснилось, что при продолжении до 14 дней результат стал бы незначимым. Какое объяснение наиболее вероятно?
AСработала случайная флуктуация, а `peeking` с `optional stopping` «поймал» шум как эффект
B`Randomization` сломалась ровно на 4-й день, поэтому результат поменялся
CКоманда перепутала `control` и `treatment`, поэтому значимость пропала
D`Alpha spending` автоматически уменьшило `effect size` задним числом
Ответ: Вероятнее всего это случайная флуктуация: `peeking` и ранняя остановка «поймали» шум, который исчез при бы продолжении.
В начале теста дисперсия высока, и метрика может случайно отклониться. Если остановить эксперимент в момент такого отклонения, вы фиксируете шум как `effect size`. При продолжении теста результат обычно усредняется и становится более стабильным. Поэтому важно использовать `fixed horizon` или корректные границы в `sequential testing`.
14Почему стратегия «остановили, как только стало значимо» часто приводит к завышенному `effect size` и `lift`?
AПотому что `effect size` при ранней остановке всегда становится несмещённым
BПотому что `lift` фиксируется ровно на истинном значении и больше не меняется
CПотому что при `optional stopping` вы чаще останавливаетесь на шумовом всплеске, и оценка эффекта систематически завышается
DПотому что `randomization` делает раннюю остановку невозможной
Ответ: При `optional stopping` вы чаще фиксируете шумовой пик (selection on significance), поэтому оценка `effect size`/`lift` склонна завышаться.
Если эксперимент останавливают в момент, когда метрика случайно оказалась выше обычного, именно это значение попадает в отчёт. При продолжении теста эффект часто «усредняется» и становится меньше. Поэтому без корректного `sequential testing` ранняя остановка может создать иллюзию большого `lift` и привести к неверным решениям.
15Если вы заранее знаете, что будете делать 5 проверок одной метрики, какой простой консервативный способ контролировать общий `alpha` можно использовать, если нет полноценного `alpha spending`?
AУвеличить `alpha` в 5 раз, чтобы компенсировать частые проверки
BРазделить трафик на 5 частей и запускать один и тот же `A/B test` по очереди
CИспользовать более строгий порог `alpha / 5` для каждой проверки
DСмотреть `p-value` только по выходным, тогда `Type I error` не растёт
Ответ: Консервативный способ: использовать порог `alpha / k` на каждую из `k` проверок (Bonferroni), чтобы ограничить общий `Type I error`.
Множественные просмотры похожи на множественные проверки, поэтому нужно компенсировать рост шанса случайной значимости. Порог `alpha / 5` делает каждую проверку строже и помогает удержать общий риск ошибки первого рода. Это может быть слишком консервативно, поэтому в продвинутых настройках используют `alpha spending` в `sequential testing`.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram