Реклама
Селектел, перетяжка, 22.06
Селектел, перетяжка, 22.06
Селектел, перетяжка, 22.06

Как устроены рекомендации с LLM: холодный старт, RAG и zero-shot ранжирование

Разбираем, как LLM меняют рекомендации: семантический поиск, RAG, cold start, zero-shot ranking, персонализация и latency.

Обложка: Как устроены рекомендации с LLM: холодный старт, RAG и zero-shot ранжирование

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

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

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

Допустим, клиент выбирает большую 4-местную кемпинговую палатку (Фактор А) и одновременно добавляет в корзину два детских спальных мешка (Фактор Б). LLM не просто ищет товары с тегом «кемпинг» . Она сопоставляет эти данные со своими знаниями о мире и делает логический вывод (Вывод В): планируется семейный выезд на природу с маленькими детьми. На основе этого синтеза система рекомендует не банальный фонарик, а мощный фумигатор повышенной безопасности для закрытых тентов или портативный подогреватель детского питания, работающий от прикуривателя.

Где потолок?

За последние десять лет двухступенчатый конвейер retrieval-ranking стал стандартом индустрии рекомендаций: сначала быстрый алгоритм генерирует сотни кандидатов из каталога, а затем тяжелая модель ранжирует этот шорт-лист, предсказывая вероятность клика. Этот подход работает отлично, но имеет пределы. Команды разработки постоянно сталкиваются с тремя фундаментальными проблемами:

  1. Холодный старт. Стандартные подходы полностью зависят от активности аудитории. При загрузке в онлайн-кинотеатр нового фильма алгоритмы чистой коллаборативной фильтрации сталкиваются с проблемой «нулевого вектора»  (отсутствием строки или столбца взаимодействий в матрице). Система не может рассчитать близость нового объекта к интересам пользователей, из-за чего новинки могут неделями оставаться мертвым грузом на дне каталога. 
  2. Проблема «усредненного товара». В классических системах и покупатель, и товар — это лишь векторы в пространстве. Когда пользователь вводит сложный запрос (например, «мощный игровой ноутбук, который не перегревается и выглядит строго для офиса»), классический алгоритм пытается найти точку где-то посередине между мощностью и дизайном. В итоге вектор запроса смещается в зону универсальных домашних ноутбуков, которые не тянут игры и выглядят дешево. В этом случае система усредняет координаты, теряя специфические требования. LLM же не усредняет, а рассуждает: она видит каждое условие как отдельный логический фильтр и ищет товар, который удовлетворяет всем критериям одновременно. 
  3. Гибкость без переписывания кода. В традиционной архитектуре признаки товара жестко заданы инженерами (цена, бренд, категория). Если бизнес хочет внедрить новый критерий, например «экологичность материалов», начинается долгий процесс: нужно нанять людей для разметки тысяч товаров, изменить структуру базы данных и переобучить модель. Это занимает месяцы. В LLM-архитектуре этот признак уже существует бесплатно. Модель может извлечь информацию об экологичности напрямую из описаний или отзывов в момент запроса. Не нужно менять код или переучивать систему, достаточно просто попросить модель учитывать этот параметр. 

Уровни интеграции LLM: архитектура LLMERS

Интеграция LLM в рекомендательные системы требует разделения контуров вычислений. Важно разделять архитектуры: если классические трансформеры в RecSys (например, модели класса BERT4Rec) оптимизированы под обработку последовательностей action_id и ID товаров, то большие генеративные языковые модели работают с сырым текстом и смыслами. Если заставить тяжелую авторегрессионную LLM обрабатывать каждый клик пользователя в реальном времени, серверная инфраструктура рухнет из-за огромных задержек ответа (latency).

Ключевые паттерны интеграции (на примере e-commerce):

  • Обогащение данных и генерация качественного контента в офлайне. Базовый холодный старт на основе текстовых описаний или картинок успешно решался и до эпохи LLM. Сила LLM в другом — она толерантна к качеству входных данных и умеет доставать сложные скрытые интенты. Если у нового товара скудное, хаотичное описание от поставщика и одна размытая фотография, старые модели выдадут бесполезный вектор. LLM же способна достроить контекст: исправить текст, вытащить неявные характеристики и, главное, сгенерировать портрет целевой аудитории. Полученный чистый, обогащенный текстовый профиль затем передается стандартным контентным моделям. Система понимает реальную ценность новинки до первого клика, даже если исходная карточка товара была заполнена ужасно. 
  • Семантическое индексирование. Вместо случайных числовых ID языковая модель присваивает товарам смысловые хэши. Все палатки для кемпинга одной категории будут иметь схожие префиксы кода, что помогает графовым сетям улавливать близость объектов без опоры на историю чужих покупок.
  • Контрастивное обучение. Модели анализируют паттерны поведения на разных слоях: от многолетних привычек до короткой текущей сессии. Затем алгоритмы квантования сжимают эти знания в компактные векторы профилей, радикально снижая объем данных, поступающих в продакшен.
  • Дистилляция знаний. Тяжелая модель (учитель) размечает тысячи сложных сценариев выбора в офлайне, логически аргументируя связи. На этих идеальных данных тренируют легковесную нейросеть (ученика). В онлайне работает только быстрый ученик, отдавая ответы за миллисекунды, но сохраняя смысловую точность большой системы.
  • Zero-shot ранжирование. На самом последнем этапе шорт-лист из 20 релевантных кандидатов передается в промпт для LLM, которая пересортирует их с учетом последних действий пользователя. Это дает высочайшую точность смыслов, но применяется точечно из-за высоких задержек.

Защита от галлюцинаций: мощь паттернов RAG

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

Для жесткого контроля трансформеров инженеры применяют пайплайны Retrieval-Augmented Generation (RAG). Механизм работает в три этапа:

  1. Семантический поиск. База данных (векторное хранилище) отбирает топ реальных продуктов из каталога на основе текущего запроса клиента.
  2. Формирование контекста. Система автоматически собирает системный промпт, оборачивая в него строгие факты (точные артикулы, цены, характеристики) о найденных товарах.
  3. Аналитическая генерация. LLM выдает финальный результат или текстовую консультацию строго в рамках переданного узкого списка товаров, теряя возможность выдумать что-то новое.

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

Шаг к агентным системам будущего

Мы наблюдаем важнейший эволюционный переход: статические алгоритмы уступают место агентным рекомендательным системам (Agentic Workflows). Классическая модель просто получает данные и отдает результат. Агент же способен вести диалог, логически рассуждать и вызывать сторонние инструменты по API.

Рассмотрим пример с выбором экипировки. Если пользователь вводит нестандартный запрос, например, «палатка для выезда с детьми в Карелию на выходные», то обычная матричная система просто выдаст витрину популярных моделей из категории «Туризм», проигнорировав нюансы.

LLM-агент работает иначе: он превращает строку поиска во вдумчивого аналитика. Используя метод пошагового рассуждения (Chain-of-Thought), нейросеть перед выдачей результата формирует скрытый внутренний логический монолог:

  • Анализ аудитории. В запросе указаны дети. Значит, в приоритете повышенная защита от насекомых, плотное дно и хорошая вентиляция.
  • Анализ формата. Задача — поход на выходные. Это классический кемпинг, куда, скорее всего, поедут на машине. Следовательно, вес палатки не критичен и можно пожертвовать легкостью ради большого тамбура и высокого потолка.
  • Анализ локации. В Карелии высокая влажность и вероятность дождей. Требуется двухслойная конструкция с высоким показателем водонепроницаемости тента (от 4000 мм в.ст.).
  • Формирование фильтров. Ищем: кемпинговая палатка, 3-4 места, двухслойная, водостойкая, с москитными сетками.

Только после завершения этой скрытой цепочки умозаключений система обращается к базе данных каталога и выводит на экран идеально подходящие товары. Более того, агент может сразу сгенерировать короткое объяснение для пользователя: «Эта модель весит чуть больше аналогов, зато у нее есть большой тамбур, можно переждать карельский дождь».

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

Персонализация и миф одного запроса

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

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

Новые метрики: почему точности мало

Традиционно качество измеряли метриками конверсии (CTR, Conversion Rate) и угадывания конкретного клика (Hit Rate). Но семантический подход требует перехода к концепции Beyond Accuracy. Оптимизация только под вероятность клика приводит к информационному пузырю и система может назойливо предлагать детективы целый месяц после одной покупки.

Новые классы метрик эффективно лечат эту болезнь:

  • Контролируемая серендипность. Оценивает внезапные приятные сюрпризы. Если любителю детективов предложить аудиокнигу про историю джаза (похожую по нуарной атмосфере), он будет искренне доволен. Классика не смогла бы проложить такой маршрут.
  • Внутрисписочное сходство (разнообразие). Оценивает способность собрать подборку из фильмов абсолютно разных жанров, каждый из которых при этом точно попадает во вкус зрителя.
  • Объяснимость рекомендаций. Способность нейросети генерировать короткие тексты-подсказки (например, «Я советую вам этот курс, так как вы недавно искали статьи по Python»). Это повышает прозрачность и снижает барьер недоверия.
  • Калибровка. Жесткая проверка честности системы. Выдача обязана соответствовать реальным долговременным интересам пользователя, не скатываясь в дешевый кликбейт.
  • Покрытие каталога. Показывает глубину поиска. Семантический векторный движок обязан эффективно поднимать хорошие товары из самого длинного «хвоста» базы.

Инженерные барьеры и безопасность данных

Внедрение умных технологий всегда несет риски. Команды разработки регулярно решают сложнейшие инфраструктурные ребусы:

  1. Время задержки сервера (Latency). Пользователь ждет результат миллисекунды, а гигантские трансформеры думают секундами. Инженерам приходится агрессивно кешировать результаты, батчить запросы и выносить максимум расчетов в офлайн-процессы.
  2. Приватность и дообучение. Логи пользователей нельзя отправлять во внешнее облако. Приходится разворачивать локальные открытые модели внутри закрытого контура компании. Для экономии ресурсов видеокарт применяют методы адаптеров (PEFT): базовые веса замораживаются, и тренируются только крошечные слои, что позволяет быстро адаптировать нейросеть под специфику магазина.
  3. Проблема выравнивания (Alignment). Базово LLM учится просто предсказывать следующее слово. Но продуктовой команде нужно растить бизнес-метрики (например, время удержания в приложении). С помощью обучения с подкреплением (RLHF) поведение модели подстраивают под реальные бизнес-цели компании.

Если на практике: мультимодальная языковая модель

Пример такого технического внедрения — мультимодальная языковая модель (MMLM) команды AI VK. Она сравнивает контент по смыслу и тематике, объясняет комментарии, описывает интересы пользователя к конкретным сценам и учитывает эмоциональный тон материалов. Нейросеть обучена более чем на трех миллионах русскоязычных материалов и может анализировать видео, изображения, тексты и аудио. С ней рекомендательные алгоритмы быстрее показывают новый контент в продуктах VK без необходимости получения первых пользовательских реакций.

Чек-лист: когда стоит внедрять технологию

Решение о трансформации должно иметь четкий финансовый расчет. Оцените ваш продукт перед внедрением LLM.

Дайте зеленый свет экспериментам, если:

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

Включите красный свет, если:

  • Сценарии потребления просты и рутинны (заказ бумажных полотенец, покупка кабеля по известному артикулу).
  • Намерение пользователя прозрачно и не требует глубокого анализа.
  • У вас жесткие аппаратные ограничения на обработку онлайн-запросов (вы просто сожжете бюджет на аренду GPU без выгоды для бизнеса).