23 июля 2026 года The New Stack выпустил материал о том, почему персонализация ранжирования в цифровых продуктах чаще ломается не из-за слабых моделей и не из-за нехватки данных, а из-за архитектуры. Для русскоязычных команд это довольно практичный сигнал: если поиск, рекомендации, фильтры, бизнес-правила и ML живут в разных сервисах, пользователь почти наверняка увидит не то, что хотел, даже если данные у компании формально есть.
Поводом стал спонсорский текст Vespa.ai, где автор Дженни Моррис разбирает персонализацию не как красивую надстройку над поиском, а как задачу принятия решения в момент запроса. Идея простая, но для многих команд неприятная: система должна в миллисекундах решить, какой объект поставить в следующий слот выдачи, одновременно учитывая текст запроса, историю пользователя, свойства товара или контента, наличие на складе, свежесть, цену и коммерческие приоритеты. Пока всё это раскидано по отдельным контурам, никакая витрина не спасёт.
В статье перечислены сигналы, которые обычно приходится сводить вместе: намерение пользователя, качество и содержание объекта, поведенческая история, ограничения доступности и бизнес-цели. Проблема в том, что они живут в разном времени. Атрибуты каталога меняются сравнительно медленно, цены и остатки могут плавать в течение дня, предпочтения пользователя двигаются после каждого клика, а внешний контекст вроде погоды, локальных новостей или спортивного события вообще может перевернуть выдачу без предупреждения. Отсюда и главный тезис: узкое место не в сборе сигналов, а в том, как собрать их в один порядок результатов прямо во время запроса.
Дальше Моррис довольно точно проходит по типичному стеку. Классические поисковые движки сильны в лексическом совпадении, но пользователи редко формулируют запросы языком каталога. Векторные базы данных, наоборот, хорошо ловят семантическую близость, однако сами по себе не решают задачу ранжирования, где нужно смешивать embedding-похожесть с наличием товара, маржинальностью, свежестью, юридическими ограничениями и ручными правилами бизнеса. После этого обычно появляются re-ranker, feature store, рекомендательный сервис и набор исключений «на коленке». Каждый новый слой добавляет задержку, а каждая граница между системами создаёт шанс, что часть сигналов устареет раньше, чем доберётся до финального скоринга.
Критика здесь попадает в боль многих продуктовых и e-commerce-команд. Когда ранжирование строится вокруг офлайн-пайплайна, каталог обрабатывают пакетно, заранее считают оценки и раздают их до следующего пересчёта. Такой подход ещё терпим, пока интересы пользователя меняются медленно. Но если самый ценный сигнал прилетел две секунды назад, ночной batch превращается в музейную экспозицию. Пользователь кликнул по двум жёлтым платьям, а система продолжает вести себя так, будто этого не было. Для контентных лент, новостных приложений, маркетплейсов и job-платформ это уже не мелкий дефект, а прямая потеря конверсии и доверия.
В качестве альтернативы Vespa предлагает единый пайплайн, где текстовый поиск, векторная близость, фильтрация по структуре данных, ranking expressions, тензорные вычисления и inference моделей живут внутри одного запроса. На практике это означает, что retrieval и ranking не разорваны на несколько сервисов с последующим «склеиванием». Лексический поиск, semantic search, фильтры, данные сессии и атрибуты объекта участвуют в одном процессе с самого начала. Для разработчика это не просто вопрос удобства. Это меняет саму форму задачи: нужные сигналы участвуют в решении тогда, когда система ещё выбирает результат, а не пытается косметически доукрасить уже найденный список.
Автор приводит упрощённую формулу итогового скоринга, где итоговая оценка складывается из лексической релевантности, семантической похожести, пользовательской аффинности, доступности и бизнес-приоритета. Смысл не в конкретных весах, а в том, что всё это должно считаться в одной функции, а не размазываться по пяти системам и двум комитетам. Отдельный акцент сделан на том, что inference-модели тоже полезнее запускать ближе к данным, чтобы их предсказания сразу становились ranking features, а не приезжали обратно с задержкой из соседнего сервиса.
Самая предметная часть текста связана с тензорами. В Vespa тензор может быть не только плотным вектором, но и разрежённой картой признаков, матрицей или более сложной структурой. За счёт этого в одной и той же схеме можно представить и embedding, и характеристики товара, и предпочтения пользователя, и бизнес-сигналы. В примере из статьи товар хранит набор признаков вроде floral, yellow, short_sleeve и crew_neck с весами, а пользовательский профиль содержит те же ключи со своими коэффициентами интереса. Персонализация тогда превращается в довольно приземлённую математику: перемножить совпадающие признаки, просуммировать результат и добавить его в ранжирование как ещё один сигнал. Если пользователь только что кликнул по нескольким жёлтым вещам, вес признака yellow можно поднять уже на следующем запросе, без ожидания следующей ночной сборки профилей.
Что это значит для разработчиков и бизнеса
Для инженерных команд главный вывод в том, что персонализация ранжирования требует не ещё одной «умной» надстройки, а ревизии архитектуры. Если бизнес-правила реализованы как жёсткие фильтры и ручные бусты, они начинают воевать с релевантностью. Если же коммерческие цели входят в ту же ranking function, что и пользовательские сигналы, ими можно управлять тоньше: поднимать избыточный склад, не ломая интент, добавлять лёгкий exploration boost для новых продавцов, усиливать локальные сюжеты в новостях или учитывать погоду без тотального превращения выдачи в рекламную полку с зонтиками. Для продактов и e-commerce это важная развилка: либо релевантность остаётся побочным эффектом набора исключений, либо становится управляемым параметром роста.
Для рынка в целом материал интересен ещё и тем, что он расширяет разговор о поиске за пределы моды на «просто vector DB». Последние два года многие команды шли по короткому маршруту: добавим embeddings, подключим ANN-поиск, а персонализацию и правила как-нибудь прикрутим потом. Текст Vespa спорит именно с этим упрощением. Семантическая близость полезна, но она не равна ранжированию как бизнес-функции. Если продукту нужно учитывать не только смысл, но и наличие, цену, маржу, регион, легальность показа, свежесть и поведение пользователя в реальном времени, одной векторной похожести мало.
Есть и ещё один важный нюанс. Vespa в статье делает ставку на multi-stage ranking: сначала дешёвая фаза быстро сужает множество кандидатов, потом более дорогая логика применяется только к меньшему набору результатов. За счёт этого система, по утверждению компании, может работать с миллиардами документов и высоким запросным трафиком, не превращая каждый запрос в дорогой эксперимент. Для крупных платформ это хороший аргумент, потому что спор между качеством персонализации и задержкой ответа никуда не делся. Но и для средних команд вывод полезен: если скоринг слишком дорогой, проблема не обязательно в идее персонализации, иногда она в том, что вся тяжёлая математика запускается не в том месте и не в тот момент.
На выходе получается довольно трезвый диагноз: данные у компаний уже есть, не хватает способности использовать их синхронно в момент выбора результата. Поэтому следующий этап конкуренции в поиске, рекомендациях и контентных лентах, похоже, будет не вокруг самого факта наличия LLM, embeddings или feature store, а вокруг того, кто сумеет собрать всё это в один живой контур. И здесь персонализация ранжирования постепенно перестаёт быть отдельной фичей для презентации совету директоров и становится базовой дисциплиной продуктовой инженерии.