В эксперименте может вырасти crash_rate, поэтому команда хочет иметь возможность остановить тест при ухудшении, не повышая false positive по основной метрике. Что лучше сделать?
AОстановить тест, как только кому-то «показалось», что стало хуже, без формальных критериев
BЗаранее задать
stopping rule для guardrail (защитная метрика) и использовать корректный подход к промежуточным решениям (например, sequential testing/alpha spending).CНе смотреть
crash_rate до конца, чтобы не было peekingDСразу перевести 100% трафика в
treatment, чтобы быстрее понять, что происходитПравильный ответ. Для ранней остановки по рискам нужен заранее заданный
stopping rule и корректный подход к промежуточным решениям.Разбор
Если останавливать тест по «ощущениям», вы получите неуправляемое число ложных тревог. Лучше заранее определить, какие guardrail (защитная метрика) метрики мониторим и при каких условиях выключаем treatment. Для основной метрики используйте fixed horizon или alpha spending в sequential testing, чтобы не наращивать Type I error.
Проверь себя · 1/3разбор после ответа
Что лучше всего описывает
stopping rule в контексте sequential testing?Ещё вопросы по теме «Секвенциальное тестирование»
- Команда запускает `A/B test` и каждый день смотрит `p-value`; как только видит `p-value < alpha`, сразу завершает и объявляет победу. В чём главный риск такого `peeking`?
- Что лучше всего описывает `stopping rule` в контексте `sequential testing`?
- Аналитик смотрит промежуточные результаты каждый день, но команда заранее зафиксировала `fixed horizon`: тест идёт 14 дней, и решение принимают только по финальному анализу в конце. Что наиболее корректно про влияние такого `peeking` на `Type I error` для основной проверки?
- Что такое `alpha spending` в `sequential testing`?
- Почему в корректном `sequential testing` порог для ранней остановки обычно более строгий, чем в конце эксперимента?
- Все вопросы по «Секвенциальное тестирование» →