Графовые нейросети в рекомендациях: от LightGCN к гибридным KG-моделям

Почему GNN-рекомендации точнее на разреженных данных

Разреженность — главная причина, по которой рекомендации вырождаются в «показываем то, что и так купят». В типичном каталоге у большинства пользователей история — два-три действия: просмотр, добавление в корзину, редкая покупка. Матрица взаимодействий заполнена на доли процента, и чем шире каталог, тем быстрее падает плотность известных связей.

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

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

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

Измеримый эффект графовых моделей: скорость, полнота, устойчивость

Первый замер после перехода на графовый подход — доля попаданий в топ. Коллаборативная выдача опирается на частоту совместных покупок, поэтому редкие позиции в верхние строки не пробиваются и длинный хвост каталога простаивает без показов.

Метрики рекомендаций снимаем послойно: отдельно по активным пользователям, отдельно по редким сегментам. Средний показатель иначе маскирует провал на нише, а именно он определяет, увидит ли покупатель что-то кроме бестселлеров. Граф добавляет к парам «пользователь — товар» рёбра по атрибутам, категориям и совместным просмотрам.

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

Время между публикацией карточки и первым показом сжимается с дней до часов — запуск коллекции не ждёт, пока по ней наберётся история покупок.

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

Подходы к построению графовых моделей: сравнение

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

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

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

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

Как мы строим GNN-рекомендации: этапы внедрения

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

1. Разбор логов и событий. Сводим просмотры, добавления в корзину и отказы в единую временную шкалу, чистим ботов и дубли. На выходе — понимание, каких связей в данных не хватает для графа.
2. Схема связей. Фиксируем типы узлов и рёбер, их веса и направление, отдельно помечаем разреженные участки. Схема согласуется до обучения — иначе качество выдачи не с чем сравнивать.
3. Сборка витрин. Готовим обучающие и проверочные наборы по времени: прошлое — для обучения, более поздний срез — для контроля. Так исключаем утечку будущих событий в признаки.
4. Обучение модели. Учим представления узлов, следим за переобучением на редких объектах и подбираем глубину распространения по рёбрам. Холодные объекты подстраховываем контентными признаками.
5. Проверка качества. Считаем попадание в топ, разнообразие выдачи и покрытие каталога. Главный критерий — отложенный период: качество на событиях, которых модель при обучении не видела.
6. Передача в продукт. Отдаём сервис выдачи с версионированием моделей, логированием и откатом на предыдущую сборку. После релиза следим за смещением данных и дообучаем по расписанию.

Порядок этапов последовательный, но не линейный: если проверка качества провалилась, мы возвращаемся к схеме связей или витринам, а не переучиваем модель вслепую.

Артефакты проекта: схемы графа, витрины признаков, регламенты

Модель на графе живёт не сама по себе: её поведение определяется тем, как описаны связи и признаки. Поэтому проект закрывается не демонстрацией метрики, а передачей рабочего контура — команда заказчика должна уметь пересобрать граф, переобучить модель и разобрать инцидент без нашей помощи.

• Схема графа. Типы узлов и рёбер, направление связей, веса, правила слияния дублей. Схема версионируется: добавление нового типа ребра не ломает уже обученные модели.
• Описание сборки связей. Из каких событий формируется ребро, какое окно наблюдения берётся, как отсекаются случайные и накрученные взаимодействия.
• Витрина признаков. Узловые и рёбровые признаки с источником каждого, расписание пересборки, проверки на смещение распределения между витринами.
• Регламент переобучения. Триггеры запуска — накопление новых взаимодействий или просадка метрик ранжирования; порядок валидации, критерий приёмки и откат на предыдущую версию.
• Правила доступа. Роли, уровни обезличивания, разграничение витрин по чувствительности, журнал обращений к данным о поведении пользователей.
• Контроль качества. Наборы проверок входных данных, тесты целостности графа, метрики качества выдачи и порядок разбора инцидентов с указанием ответственных.
• Документация и передача. Инструкции по запуску и обучению, конфигурации окружений, схема развёртывания, разбор архитектуры с вашей командой.

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

Кейс: как графовая модель подняла попадания в топ выдачи

Каталог — это длинный хвост: большая часть позиций получает единичные взаимодействия, а топ-1% товаров собирает основную долю просмотров. Классическая коллаборативная фильтрация на таких объектах почти не обучается — вектор для товара с двумя-тремя событиями строится по шуму, и в выдачу пробиваются только раскрученные позиции.

Что изменили в модели

Мы перестроили данные в граф: узлы — пользователи, товары, категории и атрибуты, рёбра — взаимодействия и связи между атрибутами. Основой взяли графовую нейросеть LightGCN — она распространяет сигнал по рёбрам и вытягивает разреженные позиции за счёт соседей, — а сверху добавили рёбра из базы знаний: совместимость, бренд, серия. Обучение шло на сэмплированных негативах, иначе модель выучивает «популярное = релевантное».

Метрики до и после

Доля попаданий в топ-10 выросла примерно в 1,8 раза, а товары вне топ-1% по популярности стали получать заметно больше показов — 26% против 7%. Ушли три класса ошибок: зацикливание выдачи на одной категории, дубликаты вариантов одной модели в пределах экрана и рекомендации позиций, недоступных к заказу.

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

Чем отличается граф знаний от графа взаимодействий?

Граф взаимодействий собирается из логов: узлы — пользователи и объекты, рёбра — просмотр, клик, добавление в корзину, покупка, у каждого ребра вес и метка времени. Такая структура плотная и быстро устаревает, зато отвечает на вопрос «что похоже по поведению» с точностью, недостижимой для атрибутов. Слабое место — холодный старт: у нового объекта и у нового пользователя рёбер просто нет.

Граф знаний описывает предметную область, а не поведение: объект, его свойства, категорию, бренд, совместимость, ограничения. Рёбра здесь типизированы — «входит в», «аналог», «требует», «заменяет» — и задают связь объектов по смыслу, а не по частоте совместных действий. Он разреженный и меняется медленно, но даёт объяснимость: видно, через какую цепочку связей объект попал в подборку.

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

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

Технические сомнения: данные, качество, объяснимость

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

Как переживает ежедневные правки каталога?

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

Чем докажете, что граф лучше текущей выдачи?

Офлайн-замер на отложенном периоде: сравниваем recall и NDCG на равном числе позиций, отдельно считаем долю холодных товаров в топе. Финальное слово за онлайн-тестом на части трафика — офлайн не показывает, как пользователи реагируют на новую выдачу.

Как часто переобучаете модель?

Эмбеддинги обновляются по расписанию и на потоке новых взаимодействий, тяжёлое переобучение — реже, при накоплении достаточного объёма данных. Каждая версия фиксируется вместе с метриками, поэтому откат на предыдущую занимает минуты.

Что покажете в объяснении рекомендации?

Не одну причину, а путь в графе: соседей по взаимодействиям, товары-«мосты» между интересами, вклад контентных признаков. Отдаём это отдельным полем в ответе — поддержка и категорийные менеджеры видят, на чём построена выдача, и могут оспорить её предметно.

Обсудим задачу: что прислать для оценки

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

• Продукт и сценарий: что и где рекомендуем — главная, карточка объекта, рассылки; какой объект рекомендации и насколько велик каталог.
• Текущая выдача: правила, «популярное», коллаборативная фильтрация — что работает сейчас, какие метрики уже собираете и чем результат не устраивает.
• Логи взаимодействий: выгрузка событий за период с типом действия, меткой времени, идентификаторами пользователя и объекта; доля анонимного трафика и глубина истории.
• Связи объектов: категории, атрибуты, бренды, поставщики, совместные покупки — всё, из чего строятся рёбра графа, и в каком виде это хранится.
• Целевые метрики: полнота на первых K позициях, доля переходов, конверсия; как замеряете изменения и есть ли контрольная группа.
• Ограничения: время ответа сервиса рекомендаций, частота переобучения, требования к объяснимости выдачи, правила работы с персональными данными.
• Инфраструктура и роли: где считаются модели, кто отвечает за данные и доступы, как выходят обновления — можно ли менять выдачу без релиза приложения.

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