Ледяная стена e-commerce и цена каждого нового товара
Представьте новый товар на полке гигантского маркетплейса. Никакой истории продаж, отзывов, кликов. Алгоритмы смотрят на него пустым, безразличным взглядом. Это cold start. Проблема не в том, что товар не найдут - проблема в том, что даже если найдут, система не поймет, куда его поставить в выдаче. Он проиграет в ранжировании любому середнячку с десятком покупок.
Традиционные методы ломались об эту стену годами. Контентные фильтры по атрибутам, коллаборативная фильтрация для похожих товаров - все это работало с задержкой в дни, а то и недели. За это время продавец терял деньги, платформа - комиссию, а пользователь - потенциально идеальный для него товар.
Слом парадигмы: от товаров к предложениям
Команда Ozon пошла неочевидным путем. Вместо того чтобы бесконечно улучшать ранжирование самих товаров, они сменили объект. Целью стал не товар, а предложение (offer).
Разница фундаментальна. Один и тот же iPhone 16 Pro Max - это один товар (SKU). Но у десяти разных продавцов - это десять разных предложений. Разная цена, разные условия доставки, разный рейтинг продавца, разная геолокация склада. Ранжировать товары - все равно что сравнивать яблоки с апельсинами, когда у каждого яблока еще и своя цена, свежесть и продавец.
Ранжирование предложений требует другой математики. Нужно учитывать сотни динамических признаков, которые меняются каждую минуту: остатки на складе, актуальную цену у конкурентов, нагрузку на логистические цепочки в конкретном регионе.
Именно здесь старая архитектура, о которой мы писали в материале про отказ от векторного поиска, начала давать сбои. Нужен был механизм, который мог бы мгновенно «понять» новое предложение, даже если товар внутри него только что создан.
Матрица памяти: не нейросеть, а гигантская lookup-таблица
Решение получило название «матрица памяти» (Matrix Memory). Если отбросить сложные термины, это гигантская, постоянно обновляемая таблица.
| Объект | Старый подход (Embedding) | Матрица памяти (Memory Vector) |
|---|---|---|
| Новый товар | Вектор из нулей или случайных чисел | Вектор, рассчитанный на лету из признаков похожих, уже «изученных» товаров |
| Обновление | Переобучение модели раз в сутки/неделю | Online-обновление каждые несколько минут |
| Вычислительная стоимость инференса | Высокая (проход через нейросеть) | Низкая (поиск и агрегация в таблице) |
Архитектура работает так:
- Оффлайн-слой (тяжелый): Комплексные ML-модели (трансформеры, графовые сети) обрабатывают исторические данные по миллионам предложений. Они выявляют сложные паттерны: «пользователи, купившие чехол для iPhone, через 2 дня часто покупают защитное стекло», «предложения с доставкой за 1 день выигрывают у более дешевых, но с доставкой за 3». Результат этого анализа - «памятный вектор» (memory vector) для каждого изученного предложения. Эти вектора и есть строки в матрице памяти.
- Онлайн-слой (легкий): Появляется новое предложение. Система не вычисляет его вектор с нуля через тяжелую модель. Вместо этого она ищет в матрице памяти K наиболее похожих, уже изученных предложений по «легким» признакам (категория, бренд, цена, атрибуты). Затем она агрегирует (например, усредняет) их memory-вектора. Полученный вектор - это и есть мгновенная «искусственная история» для нового предложения.
Это похоже на то, как работает память в современных AI-агентах, например, в Mem0 или OpenAI Memory, но примененная к сущностям e-commerce, а не к диалогу.
Главный нюанс: качество похожести на первом шаге (online-поиск). Если искать только по категории «Смартфоны», то новый Samsung получит память от старого iPhone, и рекомендации будут некорректными. Признаки для быстрого поиска должны быть тщательно подобраны.
Инфраструктурная боль и как ее пережили
Матрица памяти для Ozon - это терабайты данных, которые должны быть доступны для чтения с задержкой в миллисекунды для тысяч онлайн-запросов в секунду. Требования к памяти и скорости доступа - запредельные.
Здесь сыграли роль два фактора. Во-первых, переход на более эффективные форматы хранения векторов и их индексации. Во-вторых, железо. Похожие вызовы стояли перед инженерами, разворачивающими рабочие станции для ИИ с терабайтом памяти, но в масштабах всего дата-центра.
Новые стандарты памяти, такие как SOCAMM2, о которых мы рассказывали в отдельном материале, были созданы как раз для таких сценариев, где объем и скорость определяют всё.
Результат: не просто метрика, а сдвиг в экономике
Внедрение матрицы памяти дало Ozon увеличение GMV на 0.9%. Цифра кажется небольшой? Это иллюзия.
Для компании с оборотом в сотни миллиардов рублей каждый десятый процента - это десятки миллионов долларов дополнительной выручки в год. Но важнее другое.
- Ликвидация мертвой зоны. Время «адаптации» нового предложения сократилось с дней до минут.
- Справедливость ранжирования. Новый, но хороший продавец с выгодным предложением получил шанс обойти старожилов не за счет скидок, а за счет лучших условий.
- Устойчивость к аномалиям. Если один продавец резко поднял цену, его memory-вектор быстро «испортился», и система переключила трафик на других, не дожидаясь падения продаж.
Это меняет саму экономику маркетплейса, делая ее более динамичной и конкурентной. Тренд, который мы видим и в других сервисах, например, в интеграции Instant Checkout в ChatGPT.
Как не надо внедрять матрицу памяти: три ошибки на старте
Попытки скопировать этот подход без понимания подводных камней обречены.
1Ошибка первая: экономия на оффлайн-слое
Соблазн: сделать легковесную модель для генерации memory-векторов, чтобы обновлять их чаще. Итог: вектора получаются низкого качества, не несут глубоких паттернов. Холодный старт заменяется на «теплый, но глупый». Инвестиции в тяжелые модели (трансформеры, как в OLMo 3.5 Hybrid) на этом этапе критичны.
2Ошибка вторая: статичный механизм агрегации
Усреднение векторов (mean pooling) - это база. Но для премиум-товаров и товаров масс-маркета вес «похожести» должен быть разным. Нужен learnable агрегатор, маленькая модель, которая учится, как лучше смешивать memory-вектора кандидатов для разных типов предложений.
3Ошибка третья: игнорирование оперативной памяти
Попытка хранить матрицу на SSD или в сетевом хранилище убьет всю затею. Задержки вырастут на порядки. Планируйте развертывание только на инстансах с огромной, быстрой RAM. Считайте не стоимость гигабайта, а стоимость миллисекунды задержки. Иногда дешевле арендовать более дорогой сервер, чем терять проценты GMV.
Матрица памяти - не панацея. Это мощный, но сложный инструмент. Он не отменяет need-поиск, не заменяет каталогизацию. Он - мост через пропасть холодного старта. Мост, который окупается первыми же продажами.
Следующий рубеж? Вероятно, переход от матрицы для предложений к персонализированной матрице для пар «пользователь-предложение». Но это уже история для другого, еще более требовательного к инфраструктуре дня.
