
Рекомендательные системы уже давно стали привычной частью нашей жизни — от Netflix до YouTube и TikTok. Но есть один особый формат контента, где классические подходы начинают буксовать — живые трансляции (live-streaming).
Почему? В отличие от фильмов или статей, у стрима нет статичного описания или заранее известного контента. Всё меняется прямо на глазах — темы обсуждений, настроение аудитории, активность зрителей. Это делает задачу рекомендаций гораздо более динамичной и сложной.
Недавно вышла статья “LLM-Alignment Live-Streaming Recommendation” (arXiv: 2504.05217), где авторы предлагают новую архитектуру LARM (LLM-Alignment for Live-Streaming Recommendation). Давайте разберёмся, что это такое и зачем нужно.
В чём проблема классических систем рекомендаций?
Обычно рекомендательные системы работают на основе ID-эмбеддингов: у пользователя и у объекта (фильма, товара, поста) есть векторное представление, и алгоритм учится предсказывать вероятность взаимодействия.
Но у live-стриминга есть две ключевые особенности:
Временная динамика — трансляция меняется каждую минуту. Контент вчера и сегодня — это разные вещи.
Слабая структура данных — у нас есть чаты, заголовки, описания, но они не всегда отражают суть происходящего.
В результате ID-эмбеддинги оказываются недостаточными.
Что предлагает LARM
Архитектура LARM строится вокруг идеи совмещения LLM-эмбеддингов с классическими ID-эмбеддингами. Основные компоненты:
-
Файнтюнинг LLM на стриминговых данных
LLM дообучается на текстах, связанных с live-стримингом (чаты, описания, транскрипты). Это позволяет модели лучше понимать контекст происходящего.
-
Выравнивание эмбеддингов
Прямо использовать LLM-эмбеддинги в рекомендательной системе нельзя — они «живут» в другой пространственной структуре. Поэтому авторы предлагают проекцию с gated-механизмом, которая адаптирует их к ID-эмбеддингам.
-
Семантические кодовые признаки (semantic code features)
Итоговое представление (LLM + ID) используется как в блоке retrieval (поиск кандидатов), так и в блоке ranking (финальное ранжирование).
Схематично это можно изобразить так:
(Потоковые данные) → [LLM Fine-tuned] → эмбеддинги
↘
(ID эмбеддинги) → [Projection + Gate] → объединённое представление → (Retrieval & Ranking)
Результаты
Авторы протестировали LARM на реальных индустриальных данных и показали:
значительный прирост качества по сравнению с базовыми моделями;
каждый компонент (LLM-эмбеддинги, выравнивание, семантические признаки) вносит ощутимый вклад (проверено через абляцию).
Это значит, что LARM не просто «красивое решение», а реально рабочая схема для продакшн-систем.
Мини-пример реализации
Для простоты рассмотрим, как можно выравнивать эмбеддинги LLM и ID в PyTorch.
import torch
import torch.nn as nn
class EmbeddingAligner(nn.Module):
def __init__(self, llm_dim, id_dim, hidden_dim):
super().__init__()
self.projection = nn.Linear(llm_dim, hidden_dim)
self.gate = nn.Sequential(
nn.Linear(hidden_dim + id_dim, hidden_dim),
nn.Sigmoid()
)
self.output = nn.Linear(hidden_dim, id_dim)
def forward(self, llm_emb, id_emb):
proj = torch.relu(self.projection(llm_emb))
combined = torch.cat([proj, id_emb], dim=-1)
gate_val = self.gate(combined)
aligned = self.output(proj * gate_val + id_emb * (1 - gate_val))
return aligned
# Пример использования
llm_emb = torch.randn(1, 768) # эмбеддинг от LLM
id_emb = torch.randn(1, 128) # ID-эмбеддинг
aligner = EmbeddingAligner(llm_dim=768, id_dim=128, hidden_dim=256)
output = aligner(llm_emb, id_emb)
print(output.shape) # → torch.Size([1, 128])
Здесь gate управляет балансом между знанием LLM и историей ID.
Выводы
LARM — хороший пример того, как LLM могут работать не только как генераторы текста, но и как источник семантических признаков для сложных задач. Особенно в сферах, где данные динамичны и плохо структурированы.
Можно ожидать, что похожие подходы будут активно внедряться в стриминговых сервисах, маркетплейсах и в целом там, где контент быстро меняется.