Я думаю, что все уже видели выступление Brian Chesky (CEO и основатель AirBnB), где он накидывал на продактов. Правда, много где его слова вообще неправильно интерпритировали, но суть не в этом.

Он озвучил один резонирующий тезис, мимо которого тяжело пройти — они сильно сократили количество A/B тестов и экспериментируют только, если у них есть гипотеза и четкое понимание, чем B лучше A. Кажется, что крайне простая и логичная вещь, зачем такая категоричность? К чему такой пафос? Но если задуматься, то можно в словах Брайна разглядеть боль, которая, вероятно, является следствием повально распространенной в индустрии заразы: куча продактов запускают рандомные эксперименты, не имея никакого вижна, стратегии, четкого плана, диагностики причино-следственных связей в препятствиях на пути к цели и т.д. Что будет делать человек, у которого стоит OKR/KPI, который хочет получить промо на ревью, но понятия не имеет, как достичь цели? Правильно, он начнет работать в режиме генератора случайных чисел в надежде, что парочка из десятка экспериментов сработают.

И тут я глянул недавний подкаст Lenny c глыбой A/B тестирования - Ronny Kohavi, где он рассказал, что в AirBnB Fail Rate экспериментов 92% и это с отрывом самый большой рейт, который доводилось ему видеть. Да и мне тоже. К примеру, у нас в Юду Win Rate давно перевалил за 50% и даже выше. Кажется, моя гипотеза подвердилась — у Брайна ПТСР.

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

Ну а как описывать правильные гипотезы и не наносить психологические травмы вашему руководству, я рассказывал ранее в рамках цикла постов про «Hypothesis Framework»: часть 1, часть 2, часть 3.

Спотифай анонсировал паблик релиз своей платформы для экспериментов — Confidence. У ребят очень развитая культура экспериментирования, и это не первый их внутренний продукт, который выкатывают в паблик (luigi, annoy, backstage и прочие), поэтому есть все шансы, что будет хорошая поддержка, как со стороны самого Spotify, так и плотная работа с коммьюнити.

Сам факт того, что выкатывается именно платформа для экспериментов очень примечателен, ибо обычно такие штуки крайне специфичны для внутренних потребностей и их тяжело вытаскивать в OS. Я припомню только Planout от Facebook, но это не платформа, а либа для описания экспериментов и стратегий сплита трафика.

У нас своя платформа для А/Б тестов — Хьюстон, но если так пойдет, то есть большой confidence, что скоро кораблями будут управлять в другом месте. К тому же, мы еще не реализовали Sequential тестирование, а у Spotify оно уже в проде. Надеюсь, что в OS версии платформы оно будет.

Пока можно записаться на private beta.
https://engineering.atspotify.com/2023/08/coming-soon-confidence-an-experimentation-platform-from-spotify/

Будет 3 версии:
- Managed service
- Плагин для Backstage (платформа от Spotify для построения developers portal)
- Сервис с API деплоящийся в вашу инфру

Еще у них клевый инженерный блог, если кто не видел, и, в частности, статьи про их культуру эксперементирования https://engineering.atspotify.com/tag/experimentation/

Один из важнеших принципов при проектировании фич — учет и обдумывание различных кейсов, а не проектирование под средний или идеальный сценарий использования. Обычное дело, когда дизайнер проектирует интерфейс на 5к IPS откалиброванном монитере и начинает с веб версии под максимальное разрешение, а большая часть юзеров открывает ваш сайт на андроиде с мелким экраном и 3g интернетом в метро. Продакт при этом всегда пользуется собственным продуктом на iPhone 14 Pro Max и макеты просит рисовать под него же.

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

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

Любой курс или статья про эксперименты учат, что нужно заранее рассчитать длительность теста и смотреть на итоговые метрики только по прошествии этого количества времени. Это попытка решить проблему подглядывания (peeking problem). Суть этого явления заключается в том, что если раскатывать тесты, как только словили статистически значимые изменения, то завышается ошибка первого рода.
 
С этой неоптимальностью мониторинга p-value индустрия предлагает бороться двумя способами:
- Fixed-horizon testing
- Sequential testing
 
Sequential тестирование подразумевает, что можно следить в near-real-time за ходом эксперимента и принимать решения, как только случаются прокрасы. Всё благодаря концепции "always valid p-value". Проблема подобного подхода в его сложности. Простые алгоритмы Sequential тестирования годятся для каких-то базовых метрик с биномиальным распределением, таких как конверсия. Более сложные метрики с непрерывным распределением или, например, ratio метрики, требуют более сложных подходов, таких как mSPRT, GST, GAVI и прочие. Для них необходимо детальное моделирование как самих метрик, так и подготовки и настройки алгоритмов с помощью симуляций, А/А тестов и прочих механизмов защиты от ошибок. А теперь представьте, что вы гоняете десятки и сотни экспериментов с десятком или сотней разных метрик.
 
Fixed-horizon testing - это как раз тот случай, когда мы заранее считаем длительность теста и не останавливаемся, пока не наберём нужную выборку. Этот подход пришел из медицины и подобных дисциплин, где нужно было расчитать количество необходимых участников исследования. В большинстве статей, которые я видел, говорится о длительности теста, когда на самом деле нужно считать размер необходимой выборки (формула расчета при использовании t-критерия в первом комментарии поста). Если вы считаете длительность теста по историческому DAU/WAU/MAU, то можете попасть в ловушку того, что во время эксперимента у вас изменятся показатели из-за сезонности, внешних изменений, включения/выключения маркетинга и по факту получите другой размер выборки за проведённые дни экспериментов. Может быть ситуация, когда у вас будет выборка больше, чем надо, а может быть и меньше. Последний кейс опасен, ибо с полной уверенностью избегания проблемы «подглядывания» в неё же и наступим.

Итого, нужно считать размер необходимой выборки, но с этим тоже есть проблема, ведь при расчёте размера выборки, используются как среднее метрики, так и дисперсия. За какой период надо их считать? Что делать с кумулятивными метриками типа ARPPU? На какой выборке? Ведь в эксперименте будет selection bias, ибо в эксперимент чаще всего попадает только часть вашей аудитории, а если, к примеру, делаете тест на мобильном устройстве, то там будет накладываться селекция релиза новой версии приложения и динамика обновления аудитории на него.
 
Но это детали, которые можно разрешить, а мякотка в другом – MDE. Чтобы посчитать размер необходимой выборки, нужно задать уровень допустимой ошибки первого рода, уровень мощности и MDE. И тут вопрос: какой MDE? Теоретически, можно прикинуть потенциал нашего изменения. Например, когда решили улучшить какую-то часть воронки, то во время исследований, поняли, что X% аудитории сталкиваются с каким-то неудобством, придумали решение, устраняющее его, поняли, насколько может улучшиться наша конверсия. Проблема в том, что решение может быть неидеальным, и эффект будет ниже потенциала. Насколько? Еще вспомним, что куча продактов и продуктовых команд проводят эксперименты несистемно, без последовательной стратегии и ресерча. Представим, что задали MDE 10%, рассчитали, что нужно 10к людей в эксперименте, а по факту наш эффект составил 9% на необходимой по размеру аудитории. Что делать?

Ваши 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. На сегодня дозу токсика я исчерпал, всем спасибо!