QA, SRM и раскатка: вопросы для собеседования (часть 3)
SRM (Sample Ratio Mismatch) — один из главных диагностических инструментов: если группы разъехались по размеру, результатам эксперимента нельзя доверять. На собеседовании спрашивают, как обнаружить SRM, какие причины за ним стоят и как безопасно раскатывать изменения после успешного теста.
Вопросы 11–15 из 20
11В `A/A test` вы заметили значимое отличие по `invariant metrics`, например по числу пользователей, попавших в эксперимент, или по распределению платформ. Что это чаще всего означает?
AАудитория «улучшилась» сама по себе, значит фича работает
BЕсть проблема в разбиении или измерениях: варианты неэквивалентны, тест невалиден.
CЭто нормально, потому что `invariant metrics` не влияют на выводы
DНужно просто увеличить выборку, и различие обязательно исчезнет
Ответ: Отклонение `invariant metrics` в `A/A test` обычно сигнализирует о проблеме в данных или рандомизации.
`Invariant metrics` должны оставаться одинаковыми, потому что продукт и логика одинаковы в обоих вариантах. Если они различаются, значит, в группы попали разные типы пользователей или часть данных теряется несимметрично. В этом случае лучше остановиться и починить разбиение/трекинг до запуска настоящего A/B.
12Вы обнаружили `SRM` (Sample Ratio Mismatch): фактическое распределение трафика 47/53 вместо ожидаемых 50/50, и тест на `sample ratio mismatch` показывает сильную значимость. Какой следующий шаг наиболее полезен для диагностики?
AРазбить счётчики по платформе, версии, источнику трафика и точкам assignment, чтобы локализовать место перекоса
BНемедленно выкатывать победивший вариант, потому что статистика уже «значима»
CЗаменить целевую метрику на другую и продолжить эксперимент без изменений
DИгнорировать `SRM` (Sample Ratio Mismatch), если целевая метрика показывает рост
Ответ: При `SRM` (Sample Ratio Mismatch) важно локализовать источник перекоса: разрезы + проверка всей цепочки assignment обычно дают самый быстрый сигнал.
Сам факт `SRM` (Sample Ratio Mismatch) говорит, что что-то пошло не так с трафиком или включением в эксперимент. Разрезы по платформам и версиям часто быстро показывают, где перекос сильнее всего, а значит — где искать причину. Параллельно важно проверить, что ключ assignment одинаков на всех шагах и что фильтры включения не зависят от варианта.
13В середине эксперимента команда изменила схему события и обновила логику подсчёта метрики, не зафиксировав версию. Какой подход к исправлению наиболее корректен?
AНичего не делать: статистика всё равно усреднит изменения
BЗафиксировать версии, привести расчёт к единому определению (в идеале пересчитать исторические данные) и при необходимости перезапустить эксперимент
CВыкинуть данные варианта A и анализировать только вариант B
DЗаменить p-value на другой критерий, чтобы не замечать изменения схемы
Ответ: Изменение определения метрики без версионирования делает сравнение некорректным и требует унификации расчёта.
Если метрика считалась по-разному в разные дни или в разных вариантах, вы сравниваете не одно и то же. В таких случаях нужно зафиксировать определение (версию) и пересчитать результаты единообразно для всего периода. Если пересчёт невозможен или смешение слишком сильное, честнее перезапустить эксперимент после исправления `logging`.
14Какое поведение p-value вы ожидаете увидеть в корректном `A/A test`, если проводить много независимых прогонов?
Ap-value всегда будет около 0.5, а ниже 0.05 не будет никогда
Bp-value будет всегда близок к 0, потому что группы одинаковые
Cp-value будет всегда равен 1, потому что эффект нулевой
Dp-value будет распределён примерно равномерно, и около 5% прогонов дадут p-value < 0.05 просто случайно
Ответ: В корректном `A/A test` p-value должен вести себя как при отсутствии эффекта, без систематического смещения.
Если статистика и данные корректны, `A/A test` имитирует ситуацию без эффекта. Тогда при уровне значимости 0.05 примерно 5% прогонов могут случайно показать «значимость» — это ожидаемо. Если значимых результатов намного больше или они повторяются стабильно, это повод искать проблему в разбиении или `logging`.
15В целом метрика в варианте B выросла, но в разрезе iOS и Android она падает в обоих сегментах. Что это чаще всего подсказывает и что стоит проверить?
AЭто доказывает баг в статистике; любые разрезы нельзя использовать
BЭто означает, что `SRM` (Sample Ratio Mismatch) автоматически отсутствует, раз общий эффект положительный
CВозможен эффект смешения сегментов (например, разный состав трафика); нужно проверить распределение пользователей по сегментам и корректность агрегации
DНужно просто смотреть только общий эффект и никогда не открывать разрезы
Ответ: Противоречие между общим эффектом и эффектами в сегментах часто означает смещение состава или некорректную агрегацию.
Если доли сегментов в вариантах отличаются, общий результат может быть «искусственным» за счёт перераспределения аудитории. В таких случаях важно проверить распределение платформ, источников трафика и других ключевых признаков, а также убедиться, что метрики агрегируются одинаково. Иногда помогает стратификация или анализ по заранее заданным сегментам. Это может быть проявлением эффекта смешения (например, парадокса Симпсона).
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram