Поиск на сайте — это «ворота в Акрополь» для онлайн‑покупок. Когда клиент знает, что ему нужно, он, скорее всего, сразу вводит запрос в поисковую строку. Именно поэтому поиск отвечает за существенную долю продаж: он помогает быстро найти нужный товар и сократить воронку покупки. Исследования показывают, что поисковые пользователи конвертируются в покупатели до 50% чаще, чем обычные посетители

Более того, лишь 15% пользователей, которые пользуются поиском, приносят около 45% выручки интернет‑магазина. Малейшее улучшение качества поиска мгновенно отражается на доходах.

В этом материале мы детально рассмотрим, какие архитектуры и подходы применяются в средних и крупных интернет‑магазинах, с какими проблемами они сталкиваются и какие решения оказываются наиболее эффективными. Эпизодически мы будем смотреть на лидеров российских маркетплейсов, поскольку они дальше продвинулись в развитии поисковых технологий и зачастую задают тренды российского рынка.

Основные проблемы поиска

Технические проблемы

Поисковая система должна выдавать результаты мгновенно (обычно в пределах 100–200 мс), даже когда каталог содержит сотни миллионов товаров и миллионы ежедневных запросов. Объём данных растёт непрерывно: добавляются новые товары, меняются описания и цены. Это создаёт нагрузку на инфраструктуру и индексацию.

Крупные маркетплейсы отмечают, что поиск по 500+ млн позиций требует гибких подходов — например, Wildberries формирует предварительные пулы выборок товаров асинхронно, чтобы не обрабатывать миллионы позиций на каждый запрос. Также технически сложно реализовать полнотекстовый поиск по «грязным» данным: описания часто содержат опечатки, сленговые названия, редкие бренды и так далее Любое несоответствие в грамматике или единицах измерения (например, «50 см» против «19,7 дюйма») может помешать точному совпадению. И из этого следует следующий пункт.

Проблемы качества данных и каталога

Как и подчёркивает эксперт из Elasticsearch, «без данных нет поиска, даже плохого». Информация о товаре должна быть чистой и унифицированной. Например, необходимо нормализовать единицы измерения (UOM) — если размеры смартфона указаны в сантиметрах у одного поставщика и в дюймах у другого, система должна привести их к общей схеме.

Надо дедублицировать карточки — на маркетплейсах легко появляются тысячи копий одного и того же товара. Отсутствие в реальном времени информации о наличии товара (стоках) приводит к неверным результатам и отменам заказов. Поэтому требуются сложные пайплайны: PIM/MDM‑системы обрабатывают приходящие данные от сотен поставщиков, выполняют валидацию (формат поля, диапазоны), синхронизируют ключевые атрибуты (размеры, цвет, бренд) и вовремя обновляют индексы.

Продуктовые и бизнес‑проблемы

Поисковая система — это не просто поиск слова, но и часть пользовательского опыта и бизнес‑модели магазина. Неправильно настроенный поиск отталкивает клиента (вызов «фрустрации» при отсутствии результата), но избыточно рекламный поиск тоже обесценивается. Нужно балансировать между органической релевантностью и промо‑размещением. В крупных проектах возникают вопросы приоритизации: каким образом продвинуть товары с высокой маржинальностью, новые поступления или товары из быстрой логистики, не жертвуя релевантностью?

Эта дилемма часто решается бизнес‑правилами и A/B‑тестами. К тому же ассортимент крайне изменчив: один день товар есть, на следующий — уже нет. Постоянные изменения ассортимента — одна из крупнейших проблем. Каждое изменение требует обновления индекса или динамического учёта наличия, иначе клиент увидит устаревшую выдачу.

Организационные проблемы

Развитие поиска затрагивает сразу несколько отделов — разработку, продукт, маркетинг, аналитику. Без налаженного взаимодействия между ними не получится быстро корректировать алгоритмы или учебные данные. Например, маркетологи могут вводить новые рекламные кампании и хотели бы оперативно «подвинуть» товары, но без согласования с отделом поиска это приведёт к непредсказуемым результатам. Большие компании зачастую создают отдельные продуктовые команды по поиску, чтобы узкая специализация специалистов (ML‑инженеров, NLP‑экспертов, бизнес‑аналитиков) могла быстро реагировать на задачи.

Бизнес‑показатели

Найти нужный товар — значит сделать продажу. Wildberries подчёркивает, что вложения в поиск многократно окупаются: их собственный движок позволил создать одну из самых быстрых систем на рынке, постоянно улучшать качество выдачи и повышать конверсию в заказ. Как сказано в интервью их руководителя: «покупатель быстрее находит и покупает, продавец эффективнее работает, а маркетплейс сохраняет рентабельность». Из этого следует логичный вывод — метрики успеха поисковой системы необходимо связывать с реальными продажами и выручкой, а не только с техническими показателями.

Современные архитектуры (BM25, векторный поиск, гибридные решения)

BM25 и полнотекстовый поиск

Традиционная основа — это информационный поиск на базе ранжирования BM25 (Lucene/Solr/Elasticsearch). BM25 хорошо работает, когда запросы и тексты совпадают по терминам, поддерживает фильтры по атрибутам (ценам, брендам, категориям). Однако чистый BM25 ограничен при понимании семантики: он не улавливает схожесть слов и не интерпретирует смысл сложных формулировок. Поэтому последние годы неизменно растёт интерес к нейронным подходам.

Векторный поиск

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

Такой подход позволяет находить релевантные товары даже при отсутствии общих слов (например, пользователь ищет «беговые кроссовки на шоссе», система найдёт «спортивные кроссовки для марафонов»). Для ускорения поиска по векторам применяются ANN‑алгоритмы (HNSW, IVF). Специализированные векторные базы (Weaviate, Milvus, Faiss, Pinecone) хорошо подходят для таких задач.

Некоторые платформы объединяют индексами сразу и текстовые, и векторные данные: например, Vespa.ai изначально проектировался как поисковый кластер с поддержкой векторных и мультиконтентных запросов, а современные версии Elasticsearch/OpenSearch имеют плагин k‑NN для поиска по векторам.

Гибридные решения

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

Классический пример по гибридному поиску: запрос «водонепроницаемые походные ботинки» покажет не только страусы с exact‑match «ботинки», но и «куртки от дождя» или «снаряжение для походов», если векторы выявят семантическую близость.

Технически это реализуется по‑разному: кто‑то объединяет топ‑k результатов из обоих источников и делает RRF‑ранжирование, кто‑то использует машинное переобучение (learn‑to‑rank) для окончательного порядка. Например, может быть настроена система, где Elasticsearch возвращает выборку (BM25) и Vespa / Weaviate — выборку по семантике, а затем внешний ранжировщик объединяет списки.

По сути гибридный поиск заполняет разрыв между тем, что пользователь печатает и тем, что ему на самом деле нужно, тем самым повышая конверсию за счёт более релевантной выдачи.

Пример реализации

Многие платформы уже включают такие возможности «из коробки» — Elastic 8.x поддерживает hybrid search DSL, Weaviate изначально сочетает векторы с фильтрами, Vespa позволяет запускать сложные поисковые цепочки с векторами и правилами.

Работа с данными и каталогами (MDM, обогащение, пайплайны)

Эффективность поиска напрямую зависит от качества данных каталога. Для этого крупные магазины внедряют MDM/PIM‑системы.

MDM (Master Data Management) — это подход к единому хранилищу мастер‑данных компании (не только товаров, но и клиентов, поставщиков и др.), обеспечивающий согласованность во всех отделах.

PIM (Product Information Management) — это подсистема MDM, нацеленная исключительно на товары: она получает и обрабатывает описания из разных источников (ERP, CRM, excel‑файлов, XML/JSON‑фидов), нормализует их и распределяет в каналы (сайт, маркетплейсы и так далее).

Например, PIM собирает числовые и текстовые атрибуты, изображения, видео, объединяет их, добавляет переводы, SEO‑контент и выгружает в поисковый индекс.

Обогащение

На этапе загрузки в индекс данные товаров часто обогащаются: добавляются синонимы, категоризация, бренды, фильтры. Процессы обогащения могут включать NLP‑анализ описаний для выделения ключевых фраз, нормализацию формата цен и дат, автоматическое вычисление новых атрибутов.

Например, если в PIM не было указан цвет «Бирюзовый», можно через синонимы сопоставить его с «Зелёный» для поисковых запросов. Другой пример: на основе анализа содержания карточки поиска нужно сформировать «усреднённый» вектор описания товара для векторного поиска.

Пайплайны индексации

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

Wildberries, например, выделяет, что для обработки 500+ млн товаров они заранее формируют оффлайн «каркас» результатов, чтобы выдержать ограничение ~200 мс на онлайн‑ответ.

Пропускаются данные через ETL, микросервисы (часто используют очереди сообщений или фреймворки типа Apache Kafka, Airflow, NiFi) и затем пушатся в хранилище (например, Elastic, Vespa, Weaviate).

Каждый шаг интеграции — от загрузки сырой информации до индексации — должен быть устойчив к сбоям и обеспечивать удобный откат, чтобы неверные изменения не повлияли на выдачу.

Очистка и нормализация

Как мы уже говорили, качество исходных данных критично. Нужно проверять форматы полей, валидировать URL картинок, удалять мусор (некорректные символы), убирать дубли. Часто к разработчикам поиска прилетают жалобы: «товар не нашёлся, хотя есть в каталоге», — и причина оказывается в том, что названия/категории не совпадают. Поэтому надёжный MDM/PIM и автоматические скрипты очистки являются неотъемлемой частью пайплайна. Свежие данные об ассортименте и наличии должны поступать мгновенно (особенно при распродажах и акциях), иначе товар может провалиться в выдаче или показаться, хотя уже распродан.

Релевантность, ранжирование, метрики

Релевантность выдачи

Главная задача поиска — выдать первыми по‑настоящему подходящие товары. При этом понятие релевантности комбинирует несколько факторов: текстовое совпадение, полноту совпадения атрибутов, трендовость товара, персональные предпочтения. Современные поисковые платформы позволяют настраивать многомерные модели ранжирования. Например, можно обучить модель на поведенческих данных (клики, покупки) так, чтобы тренировочные метки отражали удовлетворённость пользователя.

Оценка качества ранжирования

В академических исследованиях качество ранжирования измеряют метриками информационного поиска: precision/recall (сколько релевантного найдено), NDCG (учитывает порядок релевантных результатов) и др.

Ключевая метрика NDCG (Normalized Discounted Cumulative Gain) показывает, насколько релевантные товары оказались в верхней части выдачи.

Однако в реальной практике чаще смотрят на пользовательские и бизнес‑метрики. Например, клик‑сквозные метрики: CTR для поисковых результатов — доля пользователей, которые кликнули на товар из выдачи. Высокий CTR (обычно >5%) говорит о том, что пользователи находят выдачу релевантной.

Далее смотрят конверсию: сколько из зашедших по поиску сделали заказ, и так далее При этом важно делать A/B‑тесты: например, если новая модель поиска дала +10% CTR и +15% конверсии, это явный выигрыш. Поисковые платформы, такие как Vespa и Elasticsearch, поддерживают встроенные метрики (например, Elastic Search Analytics), а крупные ритейлеры строят собственную аналитику на основе событий клика и покупки.

Учёт пользовательской реакции

Сбор фидбэка от пользователей (по типу «понравился ли результат») пока редкость, но анализ косвенный: время до клика, повторные поиски по тому же запросу или быстрая смена запроса на уточняющий — всё это сигналы о неудовлетворённости. Такие сигналы можно учитывать для автоматической корректировки весов ранжирования.

В итоге, комбинируя IR‑метрики (прецизионная оценка качества выдачи) и бизнес‑метрики (CTR, конверсия, LTV, доход), компании могут получить полную картину эффективности поиска.

Масштабирование и инфраструктура

Развёртывание поисковой системы для средних и крупных eCommerce требует продуманной инфраструктуры:

Кластеры и облака

Поисковые решения обычно развёртываются в виде кластеров из десятков и сотен узлов. Elasticsearch и OpenSearch легко масштабируются горизонтально: в них можно добавлять шарды и реплики. AWS OpenSearch и Elastic Cloud предлагают управляемые решения. Vespa.ai и Weaviate также поддерживают распределённый кластерный режим.

Решение «on‑premise» vs «облако» зависит от требований: многие крупные ритейлеры используют собственные дата‑центры или гибридный подход, чтобы обеспечить низкую задержку и контроль над данными.

Пример высокой нагрузки

Яркий кейс — Wildberries: собственная поисковая система должна обслуживать миллионы запросов в сутки и каталог более 500 млн товаров. Ещё более экстремальный пример — забугорная Yahoo, которая использует Vespa. Компания заявляет, что Vespa поддерживает ~800 000 запросов в секунду на миллиард пользователей. Это иллюстрирует, какие мощности существуют и какие могут потребоваться.

Внутренние оптимизации

Для ускорения отвечающего слоя применяют кэширование часто запрашиваемых результатов (например, кэш Redis или специализированные LRU‑кэши), параллельную обработку потоков запросов и приоритетные очереди.

Многие движки (Elasticsearch, Vespa) позволяют задавать разные уровни узлов: горячие узлы с быстрыми SSD для недавних товаров, холодные — для редко меняющихся данных. Нередки схемы с несколькими индексами: основной индекс для быстрого поиска по статусу «в продаже» и отдельные фоновые индексы для архивных или промо‑товаров

Собственные движки

Как показал опыт Ozon, иногда выгоднее уйти от «коробочного» решения и оптимизировать движок под задачу. В Ozon заменили Elasticsearch на собственную реализацию на Lucene, что дало значительный прирост производительности. Wildberries аналогично построили кастомное ядро с упором на векторную выдачу и сверхнизкие задержки. Очевидно, что на таком масштабе эти инвестиции окупаются за счёт более высокой конверсии и меньшей нагрузки на оборудование.

Если свести все инфраструктурные факторы воедино, то в идеале мы должны получить баланс между скоростью индексации, быстродействием при запросе и стоимостью. При проектировании важно предусмотреть рост данных на годы вперёд и включить механизм «горизонтального масштабирования» — добавления новых машин по мере необходимости.

Персонализация и рекомендации в поиске

Поисковые системы в eCommerce всё чаще выходят за рамки простой сортировки по релевантности — они становятся персонализированными рекомендателями.

Контекстный и персональный ранжировщик

Поисковая платформа может учитывать индивидуальные предпочтения и контекст пользователя. Например, если клиент ранее покупал товары для бега, его запрос «кроссовки» вероятно отобразит модели для бега выше моделей для повседневной ходьбы. Например, в системе Wildberries при перегенерации выдачи учитываются сотни динамических факторов, включая личную историю и местоположение пользователя.

Гибрид с рекомендациями

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

Виртуальные ассистенты. Одно из перспективных направлений — мультиагентные чат‑ассистенты. Bloomreach описывает концепцию «виртуального торгового ассистента», работающего на стыке LLM, векторного поиска и персонализации.

Такой ассистент может не только по ключевым словам искать товары, но и вести диалог («Мне нужен подарок для друга‑рыбака»), автоматически уточнять параметры («Любит ли он спиннинги или фидер?») и генерировать рекомендации. Это шаг за пределы стандартного поиска и переход к сервисам, которые сами понимают контекст.

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

Рекомендации на основе трендов

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

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

Специфика B2C: высокие нагрузки и мультимодальность

В B2C eCommerce поиск сталкивается с двумя особенными требованиями.

Высокие нагрузки и объёмы

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

Кроме того, бизнес может ставить амбициозные цели роста: Wildberries, например, упоминает возможность «взрывного расширения бизнеса» благодаря легко масштабируемой архитектуре.

При проектировании платформы важно учитывать рост трафика на несколько лет вперёд и иметь планы переноса нагрузки на резервные узлы или облако.

Мультимодальные запросы

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

Аналогично растёт поиск по голосу (особенно для мобильных), а перспективно — по видео и AR‑сценариям. Таким образом, архитектура поиска должна поддерживать входные данные разных типов и быть готовой к интеграции с LLM/генеративными API, которые работают с несколькими модальностями.

В совокупности, B2C‑специфика предъявляет повышенные требования к отказоустойчивости, скорости отклика и инновациям в интерфейсе поиска, чего обычно нет, скажем, в обычном корпоративном портале.

Прогнозы на 3–5 лет

Интеграция с AI и LLM

В ближайшие годы искусственный интеллект кардинально изменит ландшафт поиска. По оценкам аналитиков, к 2026 году примерно четверть всех поисковых запросов будет обрабатываться через LLM/ассистенты. Это значит, что классические «поисковики» в привычном виде (строка + список результатов) дополнятся конверсационными интерфейсами.

Пользователи всё чаще будут задавать цель («подбери мне смартфон до 20 000 руб») и получать не просто выдачу товаров, а сгенерированные ответы с встраиваемыми предложениями.

Голосовой и мультимодальный поиск

Можно уверенно прогнозировать, что голосовые помощники (Алиса, Siri, Google Assistant) станут частью клиентского опыта. Уже сегодня поколение миллениалов активно пользуется голосовым вводом; к 2025–2026 годам доля голосовых запросов в eCommerce уверенно растёт.

Кроме того, поиск по изображениям, видео и даже дополненной реальности (AR) станет стандартом. Это означает, что систему нужно готовить к любым входящим данным: текст, фото, аудио. Векторная модель должна быть обучена на мульти‑модальных эмбеддингах, а архитектура — иметь возможность подключать модули компьютерного зрения и распознавания речи.

Генеративный поиск и рекомендации

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

Это приводит к тому, что поиск превращается в «незримого продавца», который сам донаправляет пользователя к покупке. Уже сейчас существуют различные концепции, цель которых — оптимизировать выдачу для ответов, а не кликов.

Дальнейшее развитие метрик и A/B‑тестирования

Компании будут всё активнее использовать A/B‑эксперименты и модели обучения на пользовательских данных. Появятся новые KPI «поискового опыта» — например, время до первой покупки после входа через поиск, глубина скролла и скорость решения задачи, положительные отзывы. Расширится применение RAG‑архитектур: когда на поисковый запрос движок сам обращается к внутренним базам знаний и внешним источникам (как это делает Perplexity на Vespa).

AI без данных не работает

«Без данных нет поиска, даже плохого» — эта цитата полностью отражает главный урок для eCommerce: даже внедрив самые современные алгоритмы AI и нейросетевые модели, невозможно получить качественный поиск без надёжных, чистых и структурированных данных. Качество поиска прямо пропорционально качеству каталога товаров и данных о пользователях.

Надёжные MDM/PIM и пайплайны (очистка, нормализация, обогащение) являются обязательной основой. Комбинация BM25 и векторного поиска показывает отличные результаты, однако они работают только на базе качественных данных. ИИ может расширять семантические связи и предлагать новые товары, но «мусор на входе» даст «мусор на выходе».

Да прибудет с вами конверсионный поисковый листинг!