Ваши A/B тесты недостаточно эффективны. Часть 2.
Продолжение предыдущего поста

Прежде чем перейти к каким то практикам, нужно понять от первых принципов фундаментальный источник проблем.

Вся суть "peeking problem" не в том, что мы подглядываем, ибо это не квантовая физика с ее эффектом наблюдателя, это не кот Шредингера и не какая-то магия, где от самого факта "подглядывания" может измениться объективная реальность. Проблема возникает именно тогда, когда мы принимаем решение, когда видим первый прокрас, который с большой вероятностью случаен.

Вы когда-нибудь запускали сломанные эксперименты, которые роняют ваши метрики? Согласитесь, никто не хочет узнать 2 недели спустя, что конверсия в оплату упала вдвое, или что код не триггерит нужное событие, которое необходимо для расчета метрики. Вы не узнали об этом раньше, потому что дядя с курса по А/Б-тестам или спикер с uber growth конференции сказали, что подглядывать нельзя. Только проблема в том, что ваши бизнес-потери он не компенсирует. С другой стороны, представьте, что метрика красится стабильно в течение 7 последних дней из 14, но для проведения теста требуется 18 дней. Какова вероятность того, что на 18-й день прокрас исчезнет? Это легко проверить симуляцией.

На мой взгляд, подобный пайплайн (считаем размер необходимой выборки, гоняем, пока не соберем её, смотрим на метрики и принимаем решение) далек от практической эффективности и, страхуя нас от рисков. создает кучу лишних проблем.

Как поступать проще? В следущем посте мои рекомендации.

Ваши A/B тесты недостаточно эффективны. Часть 3.

часть 1, часть 2

Рекомендации:
• Мы в юду держим тесты минимум 14 полных дней, чтобы учесть минимум 2 полных недельных цикла, так как продукт сильно подвержен недельной сезонности. Изменения в продукте часто имеют эффект новизны и могут на первой неделе давать спайк лифта как вниз, так и вверх. Так же минимальное ограничение по времени позволяет застраховать нас от флуктуаций метрик в первые дни теста на малых выборках.
• Длительность теста не должна превышать 4 полные недели, так как в таком случае мы слишком сильно забиваем квоту экспериментирования. Если изменение нельзя измерить за 4 недели и меньше, то, скорее всего, это что-то незначительное, и мы занимаемся чем-то не тем. Исключения могут быть, и на них нужно идти сознательно. В каждом продукте могут быть свои особенности, поэтому цифра может отличаться, но сам принцип сохранится.
• Проводить эксперименты нужно полными недельными циклами. Имеем 2, 3 или 4 полные недели в нашем случае.
• До эксперимента выбираем ключевые (target) и контр (guardrail) метрики, как описывал в постах про работу с гипотезами, а также статистические пороги значимости (не менее 95%) и мощности (не менее 80%). Также не забываем корректировать порог значимости при множественном сравнении.
• Так как длительность теста имеет фиксированный набор, то мы можем на исторических данных прикинуть, учитывая все особенности проведения эксперимента и точку exposure, сколько примерно может быть людей в эксперименте, и посчитать для выбранных метрик, какой MDE при какой длительности будет. Рассчитываем по той же формуле, что и размер выборки, но в уравнении неизвестным становится именно MDE. К примеру, мы делаем эксперимент на форме регистрации в мобильном приложении, поэтому мы должны рассчитать динамику адопшна новой версии апа и аудитории, которая попадает на эту форму. Понимаем, сколько примерно людей будет за 2, 3 или 4 недели, считаем MDE, и в итоге имеем линейку длительность-MDE.
• Задаемся вопросом: «Верим в достижимость такого uplift?». Или наоборот: «Достигаем ли мы необходимого результата за приемлемое время?». Вряд ли мы захотим держать тест 4 недели ради мизерного uplift и вряд ли поверим, что за это время наше небольшое изменение способно показать 25% uplift.
• Во время эксперимента трекаем кумулятивно p-value и смотрим на его динамику по дням (пример на первом изображении в комментах к посту).
• Следим за фактическим MDE (изображение 3 в комментах к посту, формула MDE для случаев групп разного размера и разной дисперсии при использовании t-критерия). Он более точный, чем рассчитанный MDE до эксперимента, так как на вход подаются фактические средние контроля, дисперсии и размеры обеих групп сравнения.
• Если прокрас отсутствует, но мы видим lift, то значит, что если изменение и есть, то оно меньше MDE.
• Если прокрас есть, но lift меньше MDE, то смотрим на его стабильность. Если прокрас единовременный, то скорее всего случайный, и нам лучше подержать тест для увеличения размера выборки ради снижения MDE и повышения мощности, если мы можем себе это позволить. Если прокрас нестабильный и не пробивает MDE, то значит, что мы находимся в флуктуациях p-value и нужно ждать либо стабилизации прокраса, либо пересечения порога MDE. Иначе мы рискуем завышением ошибки первого рода выше заданного нами порога.
• Если прокрас есть, он стабильный по дням (повторяется несколько дней подряд и не прекращается), но не пробивает MDE, то можем принимать изменение, ибо наши симуляции показали, что вероятность ошибки первого рода не растет, но ожидание пересечения порога MDE сильно понижает мощность.
• Если прокрас есть и пробивает MDE, то все четко.

Очень люблю и уважаю JTBD. Это одна из вещей, которая должна быть базой для продактов. Мы на постоянке используем Job Stories, они создают удобство категоризации и быстрого осмысления потребности пользователя и выполняемой работы, но не позволяют достаточно четко и глубоко сформировать их суть, поэтому кому то могут показаться карго культом. Новый взгляд Клемента нравится сильно больше.

JTBD по Клементу в 23 году

Алан Клемент опубликовал Pdf с описанием своего ноу-хау по валидации гипотез продуктов. Можно считать это демо-версией книги, которую он пишет уже 5й год. Я вникаю, но поделиться и обсудить уже хочется.

На картинке пример описания работы. Никаких вам Джоб сторис и стейтментов. Таблица, которая описывает многосоставную потребность пользователя через несколько аспектов мотивации: Желаемые изменения, Катализаторы и неведомая для меня сущность Key Affordances, через которые человек пытается понять будет ли продукт справляться с работой.

Интересно, что последние года полтора на своих курсах я тоже говорю про многосоставные потребности и их описание через похожие сущности, а Джоб стори / работы призываю использовать, как теги для из обозначения.

Наткнулся на интересный кейс эффекта ноцебо при приеме антидепрессантов. Ноцебо, если кто не знает, это как плацебо, но когда вызывается негативный эффект.

В общем, женщина, которая участвовала в слепом рандомизированном исследовании лечения депрессии и была в группе с плацебо, хотела убить себя приняв 26 таблеток этого антидепрессанта, как она думала. Ее госпитализировали в критическом состоянии, у нее было крайне низкое давление, несколько часов откачивали, но потом ей сказали, что это было плацебо и она резко пришла в себя.

https://www.sciencedirect.com/science/article/abs/pii/S0163834307000114

Product Development 2.0: копилоты на ИИ в продуктовых командах. Видение от майкрософт

Внедрение генеративного ИИ в продуктовые команды — захватывающая перспектива, сродни наличию второго пилота в самолете. Подобно тому, как второй пилот авиакомпании помогает капитану ориентироваться в небе, второй пилот с искусственным интеллектом помогает команде людей справляться со сложностями разработки продукта.

В команде разработчиков, которой помогает второй пилот, ИИ станет основой жизненного цикла разработки продукта, повышая гибкость разработки за счет управления процессами и минимизации ошибок. Традиционные спринты станут короче, а Co-Pilots будут проводить непрерывную аналитику рынка и использования, чтобы упростить планирование до написания кода, уменьшая потребность в нескольких встречах и помогая людям сосредоточиться на творчестве и социальном взаимодействии. Показатели успеха продукта по-прежнему будут зависеть от удовлетворенности клиентов и адаптации пользователей, но мы увидим новые показатели продуктивности команды, такие как взаимодействие человека и второго пилота, автономность выполнения задач, обучение второго пилота и точность.

https://medium.com/data-science-at-microsoft/the-era-of-co-pilot-product-teams-d86ceb9ff5c2

Тут я замечу, что агенты которые натренированы быть связующим звеном между промтом и кодом/продуктовым дизайном - это интересная часть общей тенденции к гиперавтоматизации процессов и продуктов. Авторы даже приводят какое-то исследвоание: https://arxiv.org/abs/2304.03442

Правдоподобные прокси человеческого поведения могут расширять возможности интерактивных приложений, начиная от иммерсивных сред и заканчивая репетиционными пространствами для межличностного общения и инструментами прототипирования. В этой статье мы представляем генеративные агенты — вычислительные программные агенты, которые имитируют правдоподобное поведение человека... ну-ну, может быть, конечно, но есть и скепсис у меня

Увидел в последнем посте Данилова ссылку на очень прикольный онлайн симулятор запуска A/B экспериментов и работы с приоритезацией беклога.

https://www.lukasvermeer.nl/confidence/

Можете попробовать применить правила управления экспериментами, про которые я рассказывал в недавнем цикле постов: 1, 2, 3.

Илья Бирман написал об онбординге.

— Он появляется не вовремя, мешает воспользоваться приложением, а когда информация из него нужна — её уже не найти;
— Нахваливать в нём приложение и его фичи нет смысла, человек его уже установил и запустил;
— Обучать работе с приложением — тоже, так как надо сначала внимательно всё прочитать и запомнить, а уже потом — применить эти знания в реальном интерфейсе;
— Если интерфейс действительно требует обучения (и его нельзя сделать понятнее), лучше добавить подсказки, кнопки-вопросики с подробным пояснением в сложных местах, ссылки на гайды и видеоинструкции;
— Рассказывать в нём о новых фичах тоже не стоит, так как человек обычно запускает приложение с какой-то целью, и онбординг только помешает;
— Телеграм сообщает об обновлениях в отдельном канале. Если фича понравилась, сообщение о ней легко можно переслать;
— Онбординг действительно может повысить метрики. Но это не значит, что его обязательно надо добавлять. Рассказать о чём-то пользователям можно иначе;
— Если нет никаких других вариантов рассказать о продукте, лучше сделать это онбордингом, чем не сделать вовсе;
— Онбординг проще добавить: он не взаимодействует с другими частями приложения, не добавляет новых связей, поставить его может отдельная команда.

Канал Ильи. #onboarding

Думаю, все знают, что силовые тренировки являются одним из лучших средств в рамках longevity. Однако у многих людей нет понимания того, сколько и как часто нужно тренироваться, чтобы получить необходимый результат для здоровья. Более того, у многих людей есть ассоциация, что нужно тренироваться часто и тяжело, что отнимает много времени и сил. Из-за этого многие не тренируются вовсе.

Существует мета-анализ, который проанализировал влияние силовых тренировок на снижение риска смерти от любой причины — all-cause mortality.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9209691/

«The maximum risk reduction for all-cause mortality, CVD and total cancer was obtained at approximately 30–60 min/week of muscle-strengthening activities, and the risk of diabetes sharply decreased until 60 min/week of muscle-strengthening activities, followed by a gradual decrease.»

То есть, чтобы получить максимальное снижение риска, достаточно тренироваться 30-60 минут в неделю, что, по сути, означает одну небольшую силовую тренировку в спортзале.

Очень понравилась мысль из недавнего подкаста Lenny c VP of Product в Ramp: "Каждый запрос в службу поддержки является провалом нашего продукта. Если продукт работает идеально, никому не придется обращаться в нашу службу поддержки".

Это пример мышления от первых принципов (first-principle thinking). Как только вопрос ставится таким образом, вы переключаетесь с устранения последствий (обработка тикетов) на устранение причин, из-за которых эти тикеты появляются.

Крайне неоднозначная ситуация с забастовкой сценаристов в США. Тяжело занять какую-то сторону и сделать однозначные выводы. С одной стороны, продюсеры не выполняют требования гильдии сценаристов, и киноиндустрию ждет крупнейший кризис со времен ковида, который был совсем недавно и с трудом был пережит. С другой стороны, гильдия сценаристов очевидно манипулирует. Чего стоят ее требования про регуляцию ИИ.

Вот еще попалась статья, где показаны расчеты дополнительных издержек, которые понесут компании, если выполнят требования гильдии.

К примеру, $65 млн. в год для Netflix. Чтобы показать, что это копейки, косты нормируют на выручку (% cost of revenue), и вот мы имеем, что злобная корпорация Apple жадничает какими-то 0.004% от выручки, но то, что дополнительные косты на производство фильмов/сериалов считаются относительно выручки от всей деятельности огромной корпорации, никого, конечно, не волнует.

Послушал последний выпуск подкаста Питера Аттии — «Good vs. bad science: how to read and understand scientific studies». Большая часть выпуска, как видно из названия, посвящена тому, как правильно изучать научный ресерч и проблемам в нем. На эту же тему есть книжка, про которую писал в посте.

Но для начала немного контекста: за последние лет 8-10 я прочитал больше десятка книг по физиологии и спортивной медицине, тысячи различных статей на PubMed, умудрился выдвинуть за беседами с друзьями несколько гипотез, которые потом подтверждались в научной среде, и пару раз даже попытался пробиться с research review в российский журнал но был успешно послан. Пока не начал заниматься Data Science, грешил одной очень распространенной вещью — читал выводы исследований, но не всегда читал study design, не изучал, кто автор исследования, есть ли bias, в чем гипотеза (не забываем про Type III Error), не изучал глубоко данные, не проверял смогли ли воспроизвести эффект, если пытались, и, в целом, не смотрел критически на то, что читаю. Все почему? Казалось, что в peer-review журнале фигню постить не будут и можно без проблем доверять.

Исследования бывают разных типов и их можно представить в виде иерархии. Вот основные категории:
- Individual case reports: когда рассматривается конкретный случай, как в посте про эффект ноцебо.
- Когортные исследования, где рассматриваются корреляции. К примеру, посмотреть на зависимость сердечно-сосудистых заболеваний у людей, кто в течении 10 лет ходил в сауну, и сравнить с теми, кто не ходил. Но, как мы знаем, correlation does not imply causation.
- Experimental studies, типа наших любимых A/B тестов, где есть контрольная группа и экспериментальная. При этом селекция может быть non-randomized и randomized. Понятное дело, что там, где нет случайного разбиения, может быть bias. Randomized могут быть разной степени слепоты:
- Single-blind — участники эксперимента не знают в какой они группе.
- Double-blind — участники и исследователи не знают, в какой группе оказался субъект.
- Meta-analysis — объединяются данные из нескольких исследований, которые пытаются рассмотреть один и тот же вопрос. Сами исследования в рамках такого подхода могут фильтроваться, иметь разный вес и прочее. На первый взгляд, мета-анализы кажутся прекрасным способом, потому что если одно рандомизированное исследование это хорошо, то 10 должно быть еще лучше, но если рассматривать 10 мусорных исследований, то получится такой же мусор — garbage in garbage out. Еще у таких исследований все равно может быть selection bias и confirmation bias, ибо авторы могут рассматривать только определенные исследования, игнорируя другие.

Так вот, в подкасте рассматривается способ чтения исследований, похожий на тот, к которому и я пришел со временем:
- Начинаем с абстракта.
- Пропускаем интро, если знакомы с предметом, читаем, если не знакомы.
- Изучаем дизайн эксперимента/исследования. Часто ошибки можно увидеть уже здесь.
- Изучаем данные от более низких абстракций, к более высоким. К примеру, в исследованиях про различные тренировки часто бывает информация о каждом субъекте эксперимента, его образе жизни и другом бэкграунде. От базового фундамента двигаемся к более высоким абстракциям: смотрим уже на распределения, статистики, от бэкграунда идем к результатам и динамике. Обращаем внимание в данных на выбросы и крайние случаи.
- Переходим к результатам, которые вывели авторы и к секции с дискуссией.
- В случае мета-анализов сначала изучаем каждое исследование по отдельности по принципам выше, а потом смотрим, что пишут авторы мета-анализа, и их сравнения. Изучаем дополнительно были ли в это время, какие-то другие исследования, которые авторы мета-анализа не рассматривали, какие там результаты, сравниваем.

P. S. Начал недавно читать книгу Питера — «Outlive: The Science and Art of Longevity». Попробую написать ревью, когда закончу. Предварительное мнение — очень круто.

Spotify показал демку своей платформы для онлайн экспериментов. Выглядит крайне многообещающе.

Ключевые фичи:
- sequential тесты
- ролауты
- слои и бакетизация
- гранулярная сегментация аудитории и прочие настройки селекции
- кастомизация платформы через workflows на TypeScript

У "Кинопоиска" вышел клевый спецпроект про 100 самых великих фильмов 21 века. Как и от любого рейтинга, можно подпалить своё кресло, но я уже давно преисполнился в своём сознании и получаю удовольствие. Можете просто идти по списку и смотреть все то, что не видели, и познать гармонию от созерцания великого фрактального подобия и слияния с бесконечно вечным.

В мои топ-10 "Аватар" не вошёл бы, а вот "Интерстеллар", "Прибытие", "Темный Рыцарь", "Властелин Колец: Возвращение Короля", "Пианист", "Отступники" там точно были бы, и это в придачу к "Нефть", "Начало", "Старикам тут не место", "Малхолланд Драйв", которые и у "Кинопоиска" там же. Ну, а "Нефть" - это абсолютное величие и монументальный стейтмент, впрочем, как и Дэниэл Дэй-Льюис и Пол Томас Андерсон.

P.S. ну и топ-11 это "Одержимость". Не мог не отметить, так как люблю Шазелла и эту картину, в частности.

Забавно читать всю русскоязычную «аналитику» по поводу увольнения Сэма Альтмана бордом OpenAI. Сотни поверхностных теорий, начиная от недовольных убытками инвесторов и заканчивая проблемами с утечкой, но горе контент-мейкеры даже состав этого самого борда не проверили и принципы его работы прежде, чем в спешке бежать клепать новости и делать выводы, имея нулевую информацию на руках. Зато кругом все у нас специалисты по AI и внутренней кухне OpenAI.

P. S. На сегодня дозу токсика я исчерпал, всем спасибо!

Информации становится больше, и пазл потихоньку начинает складываться.

- Как было известно с самого начала, решение уволить было резким и заранее за пределами борда почти никто не знал. При этом формулировка в духе «уволен за утрату доверия».
- Сэм, по слухам, был на полпути к поднятию очередного раунда.
- Судя по инсайдам от людей, «знакомых с внутренней кухней», Сэм Альтман топил за развитие продукта, монетизацию, развитие фичей. Все это хотел шипить как можно быстрее и прочие стандартные атрибуты из мира продуктовых технологических компаний. А Илья Суцкевер хотел безопасный этичный AI, алайнмент и топил за изначальную миссию и видение, ради которого все и создавалось. Тут конфликт, похоже, и случился, и воспользовавшись своей властью, Илюха во имя миссии решил Альтмана таки выбросить за борт, пока совсем поздно не стало. Классическая ситуация бизнес против академиков, но обычно власть у тех, у кого бабки, но не в случае OpenAI, ибо нон-профит, и борд состоит не из акционеров, которые заинтересованы в росте доходов.
- После увольнения Альтмана часть команды начала сваливать вслед.
- На сторону Сэма встали инвесторы и, как говорят, Microsoft и еще несколько VC прорабатывают вариант с возвращением Сэма & Co и последующей дезинтеграцией борда, который во имя идеи может угробить их инвестиции.

Вижу два варианта:

- Альтмана вернут, борд уберут или как-то отделят профит OpenAI от нон-профита, и продолжится все то, что было до этого, а идейных академиков либо не будет, либо отделят забором.
- Вернуть все не получится, инвесторы и клиенты после таких выкрутасов начнут диверсифицировать свои риски и активы и активно начнут юзать и развивать конкурентов, а, может, и вовсе забустят инвестиции новому проекту того же Альтмана и команды, которая пойдет за ним. Позиции OpenAI резко пошатнутся, идейные академики сделают безопасный AI со 100% алайнментом, который, правда, будет никому не нужен.

Какое мое отношение ко всей ситуации? Первая реакция была: "Какое величие просрали". Чуть-чуть подумав, стало понятно, что я рад.

Помните, я писал про то, что OpenAI обладает одной из 7 стратегических сил - cornered resources, которая выражается во владении уникальной технологией, опережающей рынок, и наличии уникальных людей, знающих, как сделать эту технологию. Так же писал, что этот метод хорош в начале, но потом перестает работать (за некоторыми исключениями типа TSMC и подобных).

После GPT-4, по сути, качественного скачка не было и, судя по всему, все внимание было уделено инфре, которая была бы способна выдерживать нагрузку и эффективно делать инференс. Конкуренты и Open Source при этом не стояли на месте и активно сокращали отставание и привлекали инвестиции.

Сейчас мы попали в ситуацию, что защита OpenAI будет сжата до состояния "владения уникальной технологией", а "уникальные люди" разбредутся по конкурентам и применят свои знания. Конкуренция усилится, крутые LLM уровня GPT-4 и выше станут доступны сильно большему числу игроков на рынке, технологии начнут становиться доступнее, эффективнее, их качество будет расти. В общем, все то, за что мы любим прогресс и свободный и конкурентный рынок. И, наконец, получим Siri, в которой будет больше пользы, чем просто ставить таймер во время готовки.

OpenAI больше не будет защищен наличием уникальной технологии. Для создания безопасного и выровненного искусственного интеллекта требуется огромное количество денег. Доверие инвесторов подорвано. Текущая ситуация показывает, что догматичность и идеализм руководства не позволят инвесторам окупить свои инвестиции в виде прибыли, поэтому и инвесторы должны быть такими же идейными. И вот лично мне слабо верится, что OpenAI будет способен собрать так много, сколько нужно, чтобы быть, как раньше, на переднем краю.

Санта-Барбара продолжается. Илюха говорит, что сожалеет:

I deeply regret my participation in the board's actions. I never intended to harm OpenAI. I love everything we've built together and I will do everything I can to reunite the company.

Похоже, человек осознал, что натворил. И в руках этого человека было будущее безопасного AI.

Особенно это забавно, на фоне его другого твита:

Ego is the enemy of growth