Команда товарных рекомендаций «Магнита» столкнулась с классической проблемой — даже у эффективной команды рано или поздно заканчиваются свежие идеи. Привычные источники вдохновения — мозговые штурмы, анализ конкурентов и отраслевые конференции — перестали давать принципиально новые подходы. Вместо того чтобы пытаться выжать максимум из существующих методов, команда решила автоматизировать процесс генерации гипотез с помощью больших языковых моделей. Так появился LLM-пайплайн, который не просто подсказывает идеи, а анализирует историю собственных экспериментов компании и предлагает решения с учётом накопленного опыта.
Проблема неэффективности традиционных подходов стала очевидна после анализа метрик. Команда заметила, что скорость реализации гипотез растёт из квартала в квартал, а вот поток новых идей, напротив, снижается. В бэклоге накапливались задачи, которые откладывались неслучайно: либо из-за низкого ожидаемого эффекта, либо из-за высокой трудоёмкости. Решением мог стать только принципиально новый источник вдохновения, который бы не зависел от ограниченного опыта конкретной команды. В распоряжении были четыре основных способа добычи идей, но все они имели существенные ограничения.
Мозговые штурмы дают глубокое понимание продукта, но со временем команда начинает думать однотипно, зацикливаясь на привычных решениях. Анализ конкурентов позволяет быстро находить новые фичи, но практически невозможно понять, какие из них действительно работают на стороне соперника. Научные публикации и конференции — редкий источник действительно оригинальных инсайтов, но они не всегда применимы к специфике рекомендаций «Магнита». Все эти методы команды использовали, но ни один не мог предложить масштабируемого решения. Оставалась генерация идей с помощью ИИ — самый многообещающий, но и самый сложный в реализации подход.
Идея использовать LLM для генерации гипотез казалась простой, но на практике столкнулась с рядом препятствий. Обычные чат-боты вроде ChatGPT или Claude выдавали слишком общие и неконкретные предложения, так как не знали контекста работы команды. Готовые агенты и инструменты для генерации UX-гипотез также не подходили, так как были заточены под другие задачи. Единственным работающим решением стал собственный пайплайн, который собирает данные из внутренних систем и генерирует гипотезы с учётом всей истории экспериментов компании.
Технически пайплайн состоит из четырёх этапов. Сначала из системы управления знаниями Confluence выгружаются данные по всем экспериментам — от формулировки гипотезы до результатов A/B-теста. Затем скрипт оценивает бизнес-эффект каждого эксперимента: как он повлиял на выручку от рекомендаций и приложения в целом. После данные приводятся к единому формату и сохраняются в базе SQLite. На следующем этапе отдельный скрипт анализирует каждый эксперимент и формулирует ключевой инсайт — например, почему один подход сработал лучше другого. В результате получается структурированная история, которую может обработать LLM.
Ключевым элементом системы стал контекстный селектор, который отбирает только релевантные данные для конкретной задачи. Например, при генерации гипотезы для карточки товара в аптечном разделе приложения он подтянет эксперименты по PDP-страницам, работе с лекарствами и подобным форматам, а не станет загружать всю историю подряд. Это позволяет избежать перегруза модели и фокусироваться на актуальных данных. На выходе LLM генерирует гипотезы пяти типов: от консервативных, которые опираются на уже проверенные механики, до амбициозных решений, которые могут радикально изменить подход к рекомендациям.
Перед тем как гипотеза попадает к человеку, она проходит автоматическое ревью по трём критериям: дублирует ли она существующие решения, уже реализована ли, и насколько сильный потенциал несет. Для оценки используется интегральный показатель Quality Score, который объединяет все три метрики. Это позволяет отсеять заведомо слабые или дублирующиеся идеи и сфокусироваться только на самых перспективных. Продакт-менеджер получает набор гипотез с высоким баллом, среди которых может выбрать те, что лучше всего соответствуют текущим приоритетам и дорожной карте.
На пути к работоспособной системе команде пришлось решить шесть основных проблем. Во-первых, актуальность данных: ручное обновление локальной копии экспериментов не масштабировалось, поэтому был внедрён пайплайн, который автоматически синхронизирует данные с Confluence. Во-вторых, отсутствие единой метрики для сравнения экспериментов: все показатели — ARPU, конверсия, продажи с рекомендаций — были сведены к двум стандартным метрикам. В-третьих, модель часто предлагала уже реализованные механики, что было решено путём ведения реестра текущего состояния полок и явным запретом генерации таких идей.
Другие сложности включали дубликаты между запросами, отсутствие объективного критерия для оценки «хороших» гипотез и высокую долю нерабочих решений — около половины изначально предложенных идей оказывались нежизнеспособными. Для борьбы с дубликатами была внедрена оценка dup_score, а для отсева некачественных гипотез — система Quality Score. В результате команда получила работающий инструмент, который не только генерирует новые идеи, но и помогает избегать ошибок прошлого, опираясь на накопленный опыт.




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