Как мы подружили LLM с А-Б‑тестами: от сломанного BI до HTML‑отчётов с ИИ‑аналитиком внутри

Меня зовут Михаил Рязанский, я руководитель группы технической аналитики в Дзене. Группа включает в себя команды DWH, антифрода, аналитики модерации и ML‑аналитики. Вместе с Марком Хабаровым, лидом команды ML‑аналитики, мы расскажем про наш инструмент для анализа результатов А/Б‑тестов и про интеграцию в него LLM. Получилось интересно, местами — больно. Но обо всём по порядку. 

Постановка задачи: а зачем вообще смотреть дальше чисел?

Представьте классическую продуктовую команду: продакт, тестировщик, аналитик, ML‑специалист, разработчик. Они сделали что‑то важное — например, изменение в рекомендательную систему. Написали последнюю строчку кода. Что дальше?

Правильно — не сразу в эксплуатацию, а в А/Б‑тест. Смотрим: то, что должно было вырасти — выросло, что не должно было упасть — не упало. Вроде успех. Но достаточно ли этого?

Для большинства продуктов — да. Но если вы — контентная платформа с рекомендательной системой, то у вас есть три группы действующих лиц:

• платформа, её интересы выражены в бизнес‑метриках;

• пользователи, их покрывает стандартный А/Б‑тест;

• авторы, и вот тут начинаются сложности.

Изменения в рекомендательной системе способны нарушить хрупкий баланс между этими группами. Представьте: ваши изменения в социальной сети начали сильно продвигать автоблогеров. Следующее изменение — тоже автоблогеры. Ещё одно — автоблогеры. Продолжая эту логику ^[1], вы придёте к тому, что все стратегические цели пошли лесом, и ваш продукт превратился в платформу только для одной категории контента.

Аналитики, конечно, делали постанализ, но с нюансами:

1. Это необязательный шаг. Его делают, только если об этом подумали заранее, в виде ad hoc‑запроса.

2. Нет единого стандарта. Процесс анализа различается от аналитика к аналитику, от продукта к продукту.

3. Время принятия решений растёт. Пока ждёшь ad hoc‑активности, время идёт.

4. Не на все вопросы есть ответ в данных. Крупное СМИ выигрывает от изменений, другое такое же — проигрывает. Почему? Аналитик не всегда может объяснить.

Отсюда и родилась идея: перевести аналитику на расписание, унифицировать подход, добавить ИИ‑помощника, который будет находить неочевидные закономерности, и отобразить в удобном формате.

Звучит как задача на пять минут, правда?

Первая попытка: BI‑система говорит «нет»

Мы сели и крепко подумали, что поможет нам унифицировать аналитику, исключив субъективность конкретного сотрудника, и оценивать здоровье всей экосистемы, а не только привычные прокрасы?

Очевидное решение — дашборд. В нашем случае это DataLens.

Требования казались простыми:

• понятность: структурированная картина вместо просто чисел;

• удобство: любой продакт или менеджер должен разобраться;

• лаконичность: только то, что нужно;

• правило трёх секунд: каждый график подгружается не дольше трёх секунд.

Мы ожидали увидеть столбчатые диаграммы, линейные графики, таблицы топов авторов и публикаций. А увидели… ошибку ^[2]. Тяжёлая BI‑система посмотрела на наши данные, покрутилась и сообщила, что справиться с таким объёмом не может.

«Стоп, — скажете вы, — можно же оптимизировать SQL‑запросы, поиграться с количеством предагрегатов, оптимизировать источники данных, использовать прогрев кеша». И вы будете правы — мы перепробовали всё. Но в итоге пришли к выводу: инструмент просто не закрывает наши потребности ^[3] на нужном уровне.

HTML‑отчёты и бот в мессенджере

Мы решили сделать собственный инструмент — лёгкие HTML‑отчёты с единой точкой входа через бот в мессенджере.

Как это работает:

• Любой пользователь запускает бота и вводит номер А/Б‑теста.

• Если отчёт уже был подготовлен, то человек немедленно получает ссылку на скачивание.

• Если отчёта нет, то бот ставит задачу в очередь и уведомляет, когда всё готово.

Мы намеренно не будем углубляться в Python, HTML‑разметку и JavaScript — это не rocket science и не главное в нашей истории. Расскажем лучше про структуру отчёта.

Что внутри HTML‑отчёта

Страница 1: авторы и структура показов. 

Первый блок — общая аналитика по авторам. Мы смотрим на перераспределение показов между тестовой и контрольной группами.

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

Страница 2: Топ авторов. 

Здесь мы видим, как в рамках А/Б‑теста изменилось распределение разных авторов в выдаче в сравнении тестовой и контрольной групп. 

И вот тут появляется самое интересное: на этой странице живёт LLM. Она делает обобщённые выводы и помогает с поиском закономерностей. Часть черновой работы аналитиков мы переложили на модель, которая выступает в роли «микроштатного» аналитика.

Страница 3: Финансовое влияние на авторов.

Дзен — контентная платформа, и у нас есть выплаты авторам за осознанный пользовательский time spent. Поэтому важно понимать, как конкретный А/Б‑тест влияет на финансовую составляющую. Мы не пытаемся регулировать с помощью А/Б выплаты разным авторам. Нам важно ничего не уронить, потому что это влияет на доходы авторов.

Страница 4: Влияние на рекомендательную систему.

Здесь два подраздела:

• структура показов по типам рекомендуемых кандидатов: как изменился рекомендер;

• попарное сравнение авторов: ключевая фича, позволяющая сравнивать авторов, внешне похожих, но совершенно разных по поведению ^[4] внутри системы рекомендаций.

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

Вторая итерация: добавляем публикации и итоговую LLM‑страницу

Следующий шаг был очевидным — переключить фокус с авторов на их публикации. Мы добавили:

• общую статистику публикаций: количество показов и публикаций, медианную свежесть и другие параметры;

• топы публикаций: какие тематики мы начали активнее продвигать с учётом актуальности и качества материалов.

  

Когда мы научились писать качественные промпты и LLM начала хорошо справляться с анализом отдельных страниц, возник закономерный вопрос: «А почему бы не сделать итоговую страницу с выводами по всему эксперименту?»

Итоговая LLM‑страница

Это главная страница всего отчёта:

Она состоит из двух блоков:

Краткое резюме:

• общий вывод по эксперименту;

• следует ли его раскатывать и почему;

• если да, то какую тестовую группу и с каким обоснованием;

• микровыводы.

Подробные выводы:

• подробные замечания от модели;

• оценка соответствия результатов А/Б‑теста стратегическим целям компании.

Контекст для LLM мы берём из ближайших презентаций топ‑менеджмента. То есть модель знает, куда движется компания, и оценивает эксперимент в этом ключе.

Посмотрев на то, что получилось, мы решили пойти дальше и добавили:

• страницы со стандартными бизнес‑ и продуктовыми метриками: то, что обычно живёт в классических А/Б‑тестах;

• суммарное влияние всех раскатанных экспериментов за период: берём временной интервал (месяц, квартал, полгода), смотрим на состояние платформы в начале и в конце, оцениваем совокупный эффект от всех выкаток. Это позволило решить описанную выше проблему, возникающую при нарушении баланса между группами действующих лиц.

Как это реализовать у себя

Верхнеуровнево архитектура выглядит так:

Первое, с чего нужно начать: берём пользовательские журналы, добавляем к ним атрибуцию пользователя к какой‑то тестовой группе.

Помимо этого нужен словарь интересующих вас экспериментов. Не нужно считать всё подряд — токены стоят денег. Например, у нас источником сигнала служит сам бот: пользователь запрашивает конкретный эксперимент, это и есть сигнал к расчёту. Это может быть как на раннем этапе, так и когда кто‑то из топ‑менеджмента задаст вопрос и нужно быстро провести анализ. Если мы понимаем, что эксперимент ещё идёт и пользователи подсматривают его результаты, то кладём его в очередь и обрабатываем с каждым новым появлением данных.

Получив словарь и журналы, объединяем их и оставляем только нужные для нас события, которые соответствуют выбранным метрикам и параметрам. На их основе создаём подъёмные агрегаты. Когда пройдёт новый день или иной период времени, мы дописываем ещё одну партицию.

Затем собираем агрегаты за весь период и скармливаем LLM. Модель генерирует выводы и на их основе создаёт HTML‑отчёт. Этого достаточно для какого‑нибудь одного типа А/Б‑тестов. Но вы, скорее всего, захотите пойти дальше и добавить набор фильтров. А/Б‑тесты различаются между собой: для одних важны одни метрики, для других — другие. Можно сделать конфигурацию, в которой для каждого эксперимента прописаны только интересующие показатели, которые будут учитываться при генерировании отчётов.

Мы используем внутреннюю LLM, поэтому проблема конфиденциальности для нас не так остра. Если вы хотите использовать внешнюю модель (например, через API), то сделайте стандартный механизм обфускации: передавайте модели анонимизированные идентификаторы, а результат сопоставляйте с реальными значениями. Для модели это будет абстрактной строкой, а вы сможете восстановить контекст.

Итоги

Мы получили инструмент, который анализирует результаты А/Б‑тестов с учётом влияния на авторов, публикации, финансовые показатели и рекомендательную систему. Для этого аналитику больше не нужно вручную изучать каждый эксперимент. Результаты выдаются автоматически, в унифицированном формате, доступном для продакта и топ‑менеджмента.

Также мы снизили риск раскатки «зелёных» снаружи, но на самом деле токсичных фич. Ускорили принятие решений о раскатке. 

Самое ценное здесь — не технология сама по себе, а переосмысление того, что вообще означает «успешный А/Б‑тест». Зелёные метрики — это хорошо, но знать, кто именно выиграл и проиграл от изменения, — это другой уровень понимания продукта.

Если вам интересна схема конвейера и пример промпта (с вычищенными конфиденциальными данными), то пишите в комментарии, поделимся.

Авторы:

• Михаил Рязанский, руководитель группы технической аналитики в Дзене;

• Марк Хабаров, лид команды ML‑аналитики в Дзене.