Современные маркетплейсы сталкиваются с необходимостью строить собственный поиск, несмотря на наличие мощных готовых технологий. Запрос «платье на свадьбу» одинаково вводится и в Google, и в строке маркетплейса, и технология на входе почти одна и та же: найти по словам или найти по смыслу, по совпадению текста или по векторной близости, когда система понимает, что «платье на свадьбу» и «нарядное платье для торжества» выражают, скорее всего, одно и то же намерение. Но дальше пути расходятся. Веб-поиск отвечает на вопрос, какие документы похожи на запрос, тогда как маркетплейс должен показать товары, полезные конкретному покупателю здесь и сейчас, с учётом наличия, цены, доставки и персональных предпочтений. Технология на входе может быть одной, но цели разные, и это определяет необходимость собственной разработки. Со стороны кажется, что маркетплейс покупает готовую технологию, ставит её поверх каталога, и дальше всё собирается само, как сайт из готовых блоков. Ниже разберём условия, в которых живёт поиск маркетплейса, и то, как инженеры доходят до собственного движка.

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

Второй фактор — управление собственными данными и требование мгновенной реакции. Веб-поиск обновляет чужие источники в своём темпе: новый материал на одном сайте попадёт в индекс через минуту, на другом через час, и это нормально, потому что источник там чужой. У маркетплейса всё иначе: источник свой. Что куда везти и сколько это стоит, решают здесь же, внутри, и от своей системы ждут, что она отразит решение мгновенно. Задержка здесь означает потерянные деньги. Скидка на массовую категорию, выставленная часом позже, это тысячи карточек, которые весь этот час продавались по старой цене. Если остаток на складе обнулился, а поиск ещё не узнал об этом, покупатель оформит заказ, который продавец физически не выполнит: необеспеченный заказ, возврат денег, испорченный опыт для всех сторон. Обратная ошибка стоит не меньше: товар уже можно продавать, а карточка ещё не добралась до выдачи, и первые часы продаж потеряны, а для многих SKU они самые сильные. Оба сбоя об одном: как быстро собственные решения о товаре долетают до выдачи.

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

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

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

Шестой фактор — распределение запросов. Ежесуточно в поиск маркетплейса приходит от 60 до 75 миллионов запросов, а за ними стоит более 50 миллионов пользователей. Такая нагрузка требует высокой масштабируемости и отказоустойчивости. Готовые поисковые решения не всегда справляются с подобным объёмом и спецификой данных. Кроме того, маркетплейс должен обеспечивать низкую задержку для каждого запроса, чтобы не терять конверсию. Всё это вместе делает создание собственного поискового движка не прихотью, а необходимостью. Открытым остаётся вопрос, насколько далеко зайдёт эта специализация: будут ли маркетплейсы и дальше наращивать собственные движки или появятся отраслевые платформы, учитывающие описанные условия из коробки. В следующей статье серии будет рассмотрено, как система держит скорость на таком масштабе, и выяснится, что для большинства запросов ответ готов заранее, ещё до того как покупатель его напечатал.