Trisigma — про эксперименты

«Платформа A/B-тестирования Trisigma станет доступна компаниям в Армении, Грузии, Казахстане и Узбекистане»

Проблема

Авторы сначала опросили шесть практиков из екома, которые регулярно катят тесты на аудитории от миллиона человек. Картина знакомая до боли: путь от идеи до финального решения занимает от трёх месяцев до года, трафика на всех не хватает, тесты на пересекающиеся куски интерфейса приходится ставить в очередь. В итоге до теста доезжает мало гипотез, а ранние прототипы не проверяются никак, кроме как «показали коллегам и спросили, все ли ок».

Что предлагают авторы

Авторы предлагают вставить перед тестом фазу симуляции. LLM генерит 100 000 персон с возрастом, доходом, профессией и привычками в покупках, из них сэмплят 1000 штук и раскидывают 500/500 на контроль и тритмент. Дальше каждый агент через Selenium ходит по живому Amazon.com: ищет, кликает товар, применяет фильтр, покупает или уходит. Страницу парсят не в скриншот и не в сырой HTML, а в урезанный JSON только с товарами, ценами и фильтрами. Сессия обрезается на 20 действиях. Под капотом Claude 3.5 Sonnet.

Тестировали сокращение панели фильтров: в тритменте выбрасывали опции, у которых похожесть на поисковый запрос ниже 80%. Агенты в тритменте купили 414 раз против 403 в контроле, χ²(1)=5.51, p=0.03. Средний чек подрос с $55 до $61, но незначимо. Параллельно тот же тест крутили на 2 млн живых пользователей, и направление эффекта совпало.

Когда это реально нужно

Когда у вас очередь из гипотез и дефицит трафика, а решать, что катить первым, приходится на глазок. Тысяча агентов обошлась в 875 млн токенов и примерно $2900, и это заметно быстрее, чем ждать две недели набора трафика.

От себя

Я придерживаюсь такого мнения, что пока не наступила эпоха AGI и у агентов будет отсутствовать скилл к обобщению, то ценность от симуляционных пользователей низкая и они не заменят живой трафик даже в грубом приближении. Однако, идея использования агентов для приоритезации и чистки бэклога, замер приблизительного импакта и ускорение продуктового груминга выглядит очень даже неплохо.

➖Беслан Курашов, сооснователь Karpov.Courses — рассказал, как его компанию продали без него.

➖Роман Нестер, Segmento (продан Сберу) и Arteus LLM — про то, как создавал стартап и продавал его Сберу. И поделился, какие сложности вообще возникают при продаже своего бизнеса корпорации.

➖Валерий Бабушкин, BP — рассказал историю из регулярной практики: как проблема прогнозирования спроса сказывается на наличии товаров на полках.

«Надоели всем истории успеха, потому что все вроде уже понимают, сколько в них вранья, натяжек, недосказанностей. А факап заставляет тебя не просто встать на тумбочку и рассказать стих, какой ты молодец, а оказаться уязвимым и от этого настоящим. Ненастоящее нам и ИИ расскажет».

Проблема
Airbnb улучшает поиск по жилью, метрики у них конверсионные, вплоть до бронирования. Бронируют редко, куда реже, чем кликают в обычном e-commerce. Значит A/B нужно много трафика и много недель, а идей по ранжированию всегда больше, чем свободных слотов под тесты. В классических A/B физически сложно это все уместить.

Что предлагают авторы
Пользователей не делят на контроль и тест. Выдачу двух ранкеров смешивают и показывают одному человеку сразу, поэтому сравнение идёт внутри одного пользователя, а не между группами.
Смешивают через team drafting. Т.к. пользователю мы показываем результаты обоих ранкеров, то все что делает сплиттер, это рандомизация порядковых номеров для каждого элемента в выдаче (AABABB, BABBAB и т.п.)
Победителя определяют по preference margin и обычному одновыборочному t-тесту.

Когда это реально нужно
Когда узкое горлышко именно в A/B: много гипотез по ранжированию или рекомендациям, и при этом мало трафика или редкая конверсия. У Airbnb interleaving дал 50x ускорение, эксперимент забирает около 6% A/B-трафика и треть длительности, а с A/B сходится в 82% случаев. По сути это способ дёшево отсеять слабые идеи до полноценного теста.

От себя
Interleaving это не замена A/B, а предварительный фильтр для полноценного A/B. Он меряет относительное предпочтение между двумя ранкерами, а не абсолютный прирост бизнес-метрики. Разработка и интеграция tdi достаточно дорогостоящее занятие, поэтому к этой практике имеет смысл переходить только тогда, когда количество АБ над ранжированием достаточно емкое.

Проблема

Компания гоняет тысячи экспериментов, но правило «когда катить фичу» методологически прорабатывается без должного внимания. Катим, «если стат.значимо». Или «катим, если аплифт положительный». А сколько эта политика приносит в сумме по всему корпусу экспериментов, никто не считает.

Что предлагают авторы

Netflix взяли исторические эксперименты, на них применили правила «катим/не катим» по двум подходам (старый подход с вынесением вердикта по результатам и новый). Сложили по всем тестам вердикты (катим/не катим) и получили, сколько метрики каждое правило принесло бы суммарно. Хорошее правило катит больше реально плюсовых фич и меньше минусовых.

Загвоздка в том, что истинный эффект вы не знаете, у вас только замер с шумом. Наивный путь — взять замер сразу и как критерий отбора, и как размер выигрыша. Тогда вылезает winner's curse: тесты, которые выглядят лучшими, наполовину просто везучий шум, и суммарную отдачу вы завышаете сами себе.

Авторы чинят это через cross-validation. Данные каждого теста режут на две части. На одной половине правило решает «катить / не катить», на другой меряют, сколько north star реально набежало от этого решения. Отбор и подсчёт выигрыша идут по независимым данным, поэтому шум, из-за которого тест «выстрелил», больше не подкручивает оценку вверх. Так по всей истории получают честную суммарную отдачу каждого правила и сравнивают правила между собой.

Когда это реально нужно

Когда у вас много серых экспериментов и вы хотите настроить саму политику раскатки. На 123 исторических тестах Netflix новое правило дало +33% к накопленному north star против прежнего, и его в итоге внедрили. Выигрыш тут не в новом стат.методе, а в том, что порог принятия решения подобрали по реальной отдаче корпусу.

От себя

На мой взгляд, тут ловушка вот в чём: как только вы начинаете подбирать правило под свои данные, вы сами создаёте winner's curse уже на уровне корпуса. Методологически я бы страховался историческим holdout'ом и сравнением корпуса с ним, т.к. основной проблемой выбранного правила раскатки (не важно какого) является отсутствие перевалидации себя же. Можно, в принципе, тогда катить treatment всех серых тестов (и это возможно будет лучше по % выигрыша в north star, чем другое правило), но должен быть механизм перевалидации правил на эмпирических данных. Лучше holdout мне ничего в голову не пришло.