Привет! Меня зовут Иван Одинцов, я продакт-менеджер в команде товарных рекомендаций «Магнита». В какой-то момент мы упёрлись в неприятную стену: команда научилась быстро проверять гипотезы — а сами гипотезы при этом закончились. Все сильные идеи уже были в проде, а в бэклоге оседал «осадок», до которого руки не доходили неслучайно.
В этой статье я расскажу, как мы перестали «выедать» бэклог и собрали собственный LLM-пайплайн, который превращает архив прошлых экспериментов в поток новых гипотез — причём без выделенного разработчика, силами одного продакта.
Кому будет полезно. Продактам и аналитикам в рекомендациях и e-commerce, всем, кто упёрся в потолок идей, и тем, кто хочет автоматизировать рутину с помощью LLM, а не просто «спросить у ChatGPT».
С чего всё началось: запас сильных гипотез кончился
Наша работа — придумывать и проверять гипотезы, которые делают рекомендации в приложении лучше: добавляют релевантные товары, повышают выручку с реко-полок и конверсию. Каждая такая гипотеза проходит путь от идеи до A/B-теста и живёт в бэклоге как отдельная инициатива.
В какой-то момент мы заметили тревожную закономерность: два графика начали сходиться. Скорость, с которой команда закрывала задачи, росла квартал за кварталом — мы становились эффективнее. А вот приток новых идей, наоборот, медленно, но верно снижался. Запас сильных гипотез мы вычерпывали быстрее, чем он успевал пополняться.
Дело было не в том, что мы плохо работаем — наоборот. Просто источник идей оказался конечным. Лучшие гипотезы уже ушли в прод или в работу, а в бэклоге осело то, за что браться не спешили: либо заведомо низкий эффект, либо слишком высокая трудоёмкость. Нам нужен был принципиально новый и при этом масштабируемый источник идей.
Где вообще брать новые гипотезы
Прежде чем браться за что-то сложное, мы честно выписали все доступные способы добывать идеи и прикинули потолок каждого из них.
Мозговые штурмы команды. Они дают глубокую экспертизу и хорошее понимание контекста, но у этого подхода есть побочный эффект: со временем у команды складывается общий взгляд на продукт, и мы незаметно начинаем двигаться в одной колее. Потолок здесь невысокий.
Подсматривать у конкурентов на сайтах и в приложениях. Это быстро и просто, но провести реверс-инжиниринг чужих алгоритмов почти невозможно — со стороны не видно, что именно у них работает и за счёт чего. Потенциал средний.
Конференции, кулуары и научные статьи. Иногда там попадаются по-настоящему нетривиальные инсайты, но сильных докладов именно по рекомендациям выходит всего два-четыре в год, и далеко не факт, что чужой подход вообще ляжет на нашу специфику. Потолок снова низкий.
Все три способа мы и так использовали — и у каждого довольно быстро упёрлись в предел. А вот четвёртый путь оставался почти нетронутым.
Вывод. Самый большой неиспользованный потенциал был в генерации гипотез с помощью AI. Именно туда мы и решили копать. |
Почему не «спросить ChatGPT», а собственный пайплайн
Идея «давайте просто попросим LLM придумать гипотезы» звучит соблазнительно просто, но при практическом использовании быстро может прийти разочарования. Мы разобрали четыре способа технически реализовать AI-путь — и у каждого нашлись свои ограничения.
«Ванильный» чат (ChatGPT, Claude). Самый низкий порог входа, но и отдача соответствующая: окно контекста ограничено, воспроизводимости никакой, а гипотезы выходят слишком общими.
Готовый агент. За счёт многошаговости он способен выдавать более глубокие и интересные идеи. Однако сквозная генерация оказалась чересчур сложной задачей: она дорого обходится по токенам и плохо поддаётся контролю качества.
Готовые инструменты вроде Productboard AI или Maze AI. Они заточены под UX-гипотезы и пользовательские интервью — кейсов, связанных с алгоритмами рекомендаций, у них попросту нет.
Собственный LLM-пайплайн. Он воспроизводим, заточен под нашу специфику и накапливает контекст от запуска к запуску. Единственный минус — его придётся строить с нуля. Но, как показал опыт, именно накопленный контекст в итоге и решает всё.
Проще всего показать разницу на одном примере. Модель в обоих случаях одна и та же — отличается лишь то, что она знает о нас.
Ванильный» чат (ChatGPT, Claude) : «Используйте алгоритмы коллаборативной фильтрации для персонализации — TIFU-KNN, Item-based KNN, ALS, LightGCN». |
Собственный LLM-пайплайн: «Текущий TIFU-KNN хорошо ловит регулярные покупки, но слабо учитывает сложные связи между товарами — рекомендации становятся однообразными, падает serendipity. Попробуйте кандидато-генератор на GNN: он закроет слабые стороны — низкую эксплораторность и зацикленность на привычных товарах». |
Разница не в модели, а в исходных данных. Во втором случае LLM опирается на нашу историю: знает, что мы уже пробовали, что сработало, а что нет, — и потому говорит по делу.
Как устроен пайплайн: от данных до проверенной гипотезы
Пайплайн состоит из четырёх этапов. Первые три полностью автоматические, а на четвёртом в дело вступает человек.
Этап 1. Подготовка данных
Сначала карточки экспериментов выгружаются из Confluence. По каждой LLM-скрипт оценивает бизнес-эффект — как эксперимент повлиял на выручку бизнеса и реко-полок. Затем все данные приводятся к единому виду и складываются в SQLite, после чего отдельный скрипт формулирует по каждому эксперименту короткий инсайт и тоже записывает его в базу. На выходе получается структурированная история, с которой уже можно работать.
Этап 2. Генерация гипотез
Ключевой элемент здесь — контекстный селектор. Он отбирает только релевантные данные под лимит окна модели: например, для гипотез по карточке товара в Аптеке он подтянет эксперименты по PDP, по Аптеке и по схожим форматам, а не станет грузить в модель всю историю подряд.
Получив такой упакованный контекст — историю, инсайты и текущее состояние полок, — LLM генерирует гипотезы пяти типов, от близких к уже успешным до совсем новых направлений: Conservative, Transfer, Bold, Max Bold и Frontier.
Этап 3. Авто-ревью
Прежде чем гипотеза попадёт к человеку, она проходит автоматическое ревью по трём осям:
дубль — насколько идея похожа на уже запущенные тесты;
«уже делали» — пересекается ли она с историей экспериментов;
потенциал — какова вероятность и масштаб эффекта.
По итогам каждая гипотеза получает решение keep / revise / drop с обоснованием. А чтобы не просматривать всё подряд вручную, мы свели три оценки в один интегральный показатель:
Quality Score = (10 − dup_score) × (10 − done_score) × review_score. Наверх всплывают гипотезы, которые одновременно не дублируют существующее, ещё не делались и при этом потенциально сильны. |
Этап 4. Решение продакта
Наконец, продакт берёт в работу только гипотезы с высоким Quality Score. Он оценивает их реализуемость, приоритет и соответствие дорожной карте, при необходимости дорабатывает формулировку — и переносит в бэклог. В результате человек тратит время на самую ценную часть работы, отбор, а не на разгребание мусора.
Грабли, на которых мы спотыкались
На бумаге всё выглядит гладко, но дьявол, как водится, прятался в деталях. Расскажу про шесть основных проблем и про то, как мы с ними справились.
Актуальность данных из Confluence. Вручную поддерживать локальную копию в актуальном состоянии не получалось — это просто не масштабировалось. Решением стал дата-пайплайн, который сравнивает даты обновления локального документа и страницы в Confluence и при расхождении сам обновляет копию и пересчитывает метрики и инсайты.
Не было единой метрики для сравнения. В разных экспериментах фигурировали разные показатели — ARPU, конверсия, продажи с реко-полок, — и сравнивать их между собой было невозможно. Мы свели всё к двум стандартным метрикам: влиянию на ARPU рекомендаций и влиянию на ARPU приложения.
Пайплайн предлагал то, что уже в проде. Первые версии исправно генерировали механики, которые у нас давно работают. Чтобы это прекратить, мы добавили реестр текущего состояния полок и явный запрет предлагать то, что уже в продакшене.
Дубликаты между запросами. Модель не помнила, что генерировала в прошлых сессиях, и раз за разом предлагала одно и то же. Помогла оценка dup_score по 10-балльной шкале и отдельное LLM-ревью с комментарием по каждой гипотезе.
Было непонятно, что считать «хорошей» гипотезой. Без объективного критерия приходилось просматривать глазами всё подряд. Эту роль и взял на себя Quality Score: на ручной разбор теперь попадают только гипотезы с высоким баллом.
Высокая доля «нейрослопа». Около половины гипотез оказывались нерабочими — из-за неточных промптов, лишнего контекста или слишком общих формулировок. Мы покрыли логами каждый шаг генерации и шлифовали качество и руками, и агентом, но быстро упёрлись в закон убывающей отдачи: каждая дополнительная пара часов давала прирост в 1–2 % или не давала вовсе. В итоге мы признали, что часть слопа неизбежна, и просто заложили время на ручную корректировку.
Что получили
Главный результат — мы вернулись к высокой скорости генерации качественных гипотез. Разрыв между созданными и закрытыми задачами снова вырос, и заметную часть этого прироста дал именно LLM-пайплайн: +15 гипотез ушло прямо в бэклог.
Воронка одного прогона выглядит так: больше сотни структурированных артефактов на входе превращаются примерно в 200 сгенерированных гипотез, из которых около 50 проходят авто-ревью, и в финале остаётся 15 действительно качественных — те, что попадают на стол продакта и затем в бэклог.
Выводы
Напоследок — пять главных вещей, которые я вынес из этого проекта.
Структура данных важнее алгоритма генерации. Пока эксперименты лежали разрозненными PDF-ками, никакая LLM не спасала. Сначала нужно было собрать базу — качество гипотез напрямую зависит от качества исходных данных.
LLM — это инструмент, а не оракул. Модель галлюцинирует, повторяется и не знает контекста бизнеса. Наша задача — грамотно ограничить пространство поиска: реестром состояния полок, фильтрами и явными запретами.
Авто-ревью — обязательный этап. Без него львиная доля гипотез уходит в «надо доработать» или прямиком в мусор. Ревью до человека экономит время команды и помогает сфокусироваться на лучших идеях.
Итеративность важнее идеального первого решения. Первая версия была простым скриптом, а дальше каждый квартал добавлялся один новый элемент: сначала парсинг, потом реестр, потом ревью. Строить всё сразу не нужно — и даже вредно.
Продакт может быть инженером своего инструмента. Весь продукт написан без выделенного разработчика. LLM настолько снизили порог входа, что продакт вполне способен сам автоматизировать собственную рутину.
А как у вас? Сталкивались с «выеданием» бэклога? Пробовали генерировать гипотезы через LLM — и если да, то как боролись со слопом? Делитесь в комментариях, будет классно сравнить подходы.
