Векторный поиск внутри сайта: миграция с Elasticsearch на pgvector и Qdrant для роста внутренней конверсии

Анатомия проблемы: почему классический поиск на BM25 теряет до 40% лидов

В основе подавляющего большинства традиционных поисковых модулей интернет-магазинов и контентных платформ — будь то чистый Elasticsearch, OpenSearch или встроенные модули CMS — лежит алгоритм лексического поиска BM25 (модификация классического TF-IDF). Десятилетиями этот подход считался стандартом индустрии: он отлично справляется с подсчетом частотности вхождений терминов, инвертированными индексами и быстрым нахождением документов по точным словоформам.

Однако в реальном e-commerce пользовательское поведение давно изменилось. Покупатели не формулируют свои потребности точными заголовками карточек товаров из 1С или ERP. Традиционный поиск по ключевым словам теряет до 40% лидов из-за опечаток, разговорных формулировок и сложных запросов. Причины столь высоких потерь лежат в фундаментальных ограничениях лексического анализа:

• Разрыв словарного запаса (Vocabulary Mismatch Problem): если пользователь вводит «тихий пылесос для квартиры с кошкой», а в названии товара указано «вертикальный пылесос 450 Вт с турбощеткой для сбора шерсти, уровень шума 65 дБ», алгоритм BM25 посчитает релевантность околонулевой, так как слова «тихий», «квартира» и «кошка» в заголовке отсутствуют.
• Сложные атрибутивные и ситуативные запросы: формулировки вида «подарок коллеге до пяти тысяч рублей» или «что надеть на вечернюю презентацию осенью» ставят классический поиск в тупик — он пытается найти товары, содержащие слова «подарок» или «надеть», выдавая пустую страницу или нерелевантный мусор.
• Ограничения морфологии и нечеткого поиска (Fuzziness): включение встроенного нечеткого поиска (расстояние Левенштейна) в Elasticsearch частично решает проблему механических опечаток, но приводит к взрывному росту ложноположительных результатов и резкому падению производительности кластера при высоких нагрузках.
• Словарный тупик синонимов: ручная поддержка словарей синонимов (Synonym Graph Token Filter) в растущем каталоге превращается для контент-команды в бесконечный ручной труд, который невозможно масштабировать на десятки тысяч SKU и меняющиеся языковые тренды.

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

Гибридный поиск: почему плотные эмбеддинги не отменяют лексический индекс

Векторный поиск оперирует не символами, а смыслом. С помощью нейросетевых моделей текстовые описания товаров и пользовательские запросы преобразуются в плотные числовые векторы фиксированной размерности (dense embeddings) в многомерном латентном пространстве. Близость векторов вычисляется через косинусное расстояние или скалярное произведение: семантически близкие понятия («тихий» и «низкий уровень шума», «кроссовки» и «сникеры») оказываются рядом, даже если у них нет ни одной общей буквы.

Тем не менее, переход на исключительно векторный поиск (Pure Vector Search) в e-commerce несет скрытые риски. Плотные эмбеддинги идеально улавливают общую семантику и контекст, но часто проигрывают лексическому поиску при точечных запросах:

• Поиск по артикулам и SKU: запросы вида «A2141», «артикул 98452-X» или серийные номера не обладают семантическим смыслом — здесь требуется строгое посимвольное совпадение, в котором BM25 безупречен.
• Точные наименования брендов и редких моделей: векторные модели могут размывать специфические названия брендов, предлагая аналогичные по классу товары вместо конкретной запрашиваемой позиции.
• Редкие аббревиатуры и технические стандарты: специализированные обозначения (например, «ГОСТ 12.4.026» или «IP68») требуют детерминированного сопоставления.

Индустриальным стандартом высокой конверсии является гибридный поиск (Hybrid Search), объединяющий оба подхода: лексический поиск по инвертированному индексу (BM25) и семантический поиск по векторному индексу (HNSW). Результаты двух параллельных выдач объединяются с помощью алгоритма слияния рангов — чаще всего Reciprocal Rank Fusion (RRF).

Формула RRF присваивает каждому товару итоговый балл на основе его позиций в обеих выдачах: сумма обратных величин рангов с константой сглаживания. Это позволяет объединять результаты без необходимости сложной нормализации сырых оценок релевантности BM25 и косинусного сходства.

Архитектурный выбор: pgvector против специализированных векторных баз (Qdrant и Milvus)

При отказе от тяжелого кластера Elasticsearch или проектировании новой поисковой инфраструктуры перед техническим директором встает выбор: расширить возможности существующей реляционной СУБД с помощью pgvector или вынести векторные операции в специализированную векторную базу данных — Qdrant или Milvus.

Расширение pgvector для PostgreSQL: простота внедрения и транзакционная целостность

Расширение pgvector добавляет в PostgreSQL нативный тип данных vector и алгоритмы индексации HNSW (Hierarchical Navigable Small World) и IVFFlat. Это оптимальный выбор для команд, стремящихся минимизировать сложность инфраструктуры.

• Ключевые преимущества pgvector:
  • Транзакционная согласованность (ACID): обновление цены, остатков или статуса наличия товара происходит в рамках единой транзакции с обновлением вектора — исключается рассинхронизация данных.
  • Отсутствие отдельного ETL-пайплайна: нет необходимости настраивать постоянную синхронизацию данных во внешнюю поисковую систему через Kafka, Debezium или периодические дампы.
  • Объединение векторного поиска и SQL-фильтрации: векторный запрос можно бесшовно объединять с привычными условиями WHERE category_id = 42 AND in_stock = true AND price BETWEEN 1000 AND 5000 с использованием стандартных B-Tree индексов.
  • Минимальные эксплуатационные расходы: не требуется администрировать, мониторить и резервировать отдельный кластер поисковой базы.
• Ограничения и узкие места pgvector:
  • Борьба за ресурсы: построение HNSW-индекса и поиск по многомерным векторам требуют значительного объема оперативной памяти. Нагрузка от поиска может снижать производительность основной транзакционной базы (OLTP).
  • Ограниченное масштабирование: масштабирование векторных запросов упирается в стандартные механизмы репликации PostgreSQL; отсутствует нативное автоматическое шардирование векторов по нодам.
  • Порог применимости: каталоги до 500 000 — 1 000 000 товаров при умеренной поисковой нагрузке (до нескольких сотен запросов в секунду).

Qdrant: специализированный векторный движок для высоких нагрузок

Qdrant — это векторная база данных с открытым исходным кодом, написанная на Rust, спроектированная специально для векторного поиска с расширенной фильтрацией метаданных (Payload-based filtering).

• Ключевые преимущества Qdrant:
  • Высочайшая производительность и низкая задержка: реализация на Rust обеспечивает минимальные оверхеды памяти, предсказуемый latency (p99 менее 15-20 мс) и высокую пропускную способность.
  • Фильтрация полезной нагрузки на этапе обхода графа: Qdrant применяет фильтры по метаданным (категории, цены, бренды) непосредственно во время обхода HNSW-графа, что исключает деградацию полноты выдачи при строгих бизнес-ограничениях.
  • Встроенное квантование векторов: поддержка скалярного (Scalar Quantization) и продуктового (Product Quantization) квантования позволяет сжимать векторы в памяти в 4–8 раз практически без потери точности поиска (Recall).
  • Нативный гибридный поиск: движок из коробки поддерживает совмещение плотных (dense) и разреженных (sparse) векторов, позволяя реализовать связку BM25 + Dense внутри одного инструмента.
• Ограничения Qdrant:
  • Необходимость конвейера репликации данных: требуется выстраивать надежный пайплайн синхронизации метаданных и остатков из основной БД в Qdrant.
  • Операционная сложность: добавление отдельного сервиса в стек мониторинга, резервного копирования и управления инфраструктурой.
  • Порог применимости: каталоги от 500 000 до десятков миллионов позиций, высокие требования к QPS (от сотен до тысяч запросов в секунду) и сложная динамическая фильтрация.

Milvus: распределенная база данных для enterprise-масштаба

Milvus ориентирован на сверхкрупные системы с миллиардами векторов, где требуется жесткое разделение вычислительных узлов и хранилища (Compute-Storage Separation).

• Ключевые преимущества Milvus:
  • Глубокая микросервисная архитектура: независимое горизонтальное масштабирование координаторов, узлов запросов (query nodes), узлов индексации (index nodes) и узлов данных (data nodes).
  • Эластичность для гигантских объемов: способность обслуживать каталоги маркетплейсов с сотнями миллионов товаров и терабайтами векторных данных.
• Ограничения Milvus:
  • Высокий порог входа и тяжелая инфраструктура: для развертывания даже базового кластера требуются etcd, Pulsar/Kafka и S3/MinIO. Эксплуатация избыточна для 95% интернет-магазинов среднего и крупного сегмента.

Критерии выбора стека для инженерной команды

• Выбирайте pgvector, если: в компании уже используется PostgreSQL, размер каталога не превышает 500 000–800 000 товаров, критична абсолютная транзакционная согласованность остатков и цен, а выделенной DevOps-команды для поддержки отдельного поискового кластера нет.
• Выбирайте Qdrant, если: размер каталога превышает 1 000 000 SKU, поисковая нагрузка превышает 200–300 QPS, требуются встроенные механизмы квантования памяти, а также одновременная фильтрация по десяткам динамических атрибутов без потери скорости.
• Выбирайте Milvus, если: вы строите экосистему уровня федерального маркетплейса с десятками миллионов позиций и распределенной командой инфраструктурных инженеров.

Пайплайн генерации эмбеддингов для каталога: от подготовки данных до мультиязычности

Качество векторного поиска на 80% определяется не параметрами HNSW-индекса, а качеством текстового представления товаров, подаваемого на вход модели эмбеддингов.

1. Формирование текстового синтеза карточки товара

Попытка векторизовать только название товара приводит к потере важных характеристик, а векторизация всего «сырого» HTML-описания размывает вектор мусорными словами (условия доставки, рекламные слоганы, контактные данные). Необходим структурированный синтез данных:

• Канонический заголовок: название бренда + модель + базовый тип изделия.
• Дерево категорий: хлебные крошки (например, «Электроника > Бытовая техника для кухни > Кофемашины рожковые»).
• Ключевые атрибуты и фасеты: нормализованные пары «характеристика: значение» (например, «материал корпуса: металл», «давление помпы: 15 бар»).
• Исключение волатильных параметров: динамические показатели (цена, остатки на складах, скидки, размер кешбэка) ни в коем случае не должны попадать в текст для векторизации. Их место — исключительно в метаданных (payload) для жесткой фильтрации.

2. Мультиязычность, синонимы и транслитерация

В русскоязычном сегменте e-commerce постоянным вызовом являются смешанные запросы: транслитерация («айфон», «самсунг»), оригинальные латинские написания («iPhone», «Samsung») и народные сленговые термины. Применение современных мультиязычных bi-encoder моделей снимает эту проблему на фундаментальном уровне:

• Мультиязычные модели эмбеддингов проецируют смысловые эквиваленты на разных языках в одну и ту же область векторного пространства: запрос «беспроводные наушники», «wireless headphones» и «блютуз уши» формируют векторы с высоким косинусным сходством.
• Для доменно-специфичных тематик (автозапчасти, фармакология, строительные материалы) базовые модели общего назначения могут давать сбои. В таких случаях оправдано дообучение модели (Fine-tuning) на парах «поисковый запрос — кликнутый товар» из исторических логов сайта с использованием функции потерь MultipleNegativesRankingLoss.

3. Организация асинхронного конвейера индексации

В боевом окружении генерация векторов должна быть строго отделена от транзакционных операций создания и редактирования товаров в CMS:

1. Change Data Capture (CDC): изменения в карточках товаров фиксируются через логирование транзакций (Debezium / PostgreSQL WAL) или через брокер сообщений (RabbitMQ / Kafka) по паттерну Transactional Outbox.
2. Очередь векторизации: воркеры на базе Python/Go вычитывают события пачками (batch processing). Пакетная отправка текстов в инференс-сервис эмбеддингов повышает утилизацию GPU/CPU в 5–10 раз по сравнению с поштучной обработкой.
3. Индексация в хранилище: полученные векторы записываются в Qdrant или pgvector с обновлением соответствующих метаданных.

Метрики качества поиска: от математических оценок к коммерческой эффективности

Переход на векторный или гибридный поиск требует регулярного измерения качества. Оценку необходимо разделять на офлайн-метрики ранжирования и онлайн-показатели конверсии.

Офлайн-метрики качества поисковой выдачи

Офлайн-метрики рассчитываются на историческом эталонном датасете запросов (Golden Dataset) до выкатки изменений в прод:

• MRR (Mean Reciprocal Rank): оценивает позицию первого релевантного результата в выдаче. Критически важна для точечных запросов и поиска по SKU/брендам: если нужный товар находится на первой позиции, балл равен 1; если на второй — 0.5; если на десятой — 0.1.
• NDCG@k (Normalized Discounted Cumulative Gain): ключевая метрика для категорийных и широких запросов. Учитывает градуированную релевантность товаров в топ-k позиций выдачи (например, топ-5 или топ-10) со штрафом за нахождение идеальных товаров на низких позициях.
• Zero-Result Rate: процент запросов, вернувших пустую выдачу (0 товаров). Внедрение семантического поиска снижает эту метрику в разы, напрямую сокращая отток пользователей.

Онлайн-метрики и влияние на бизнес

Окончательный вердикт эффективности выносится на основе продуктовых и коммерческих метрик через A/B-тестирование:

• Search-to-Cart Conversion Rate: доля поисковых сессий, в рамках которых пользователь добавил хотя бы один товар из выдачи в корзину.
• Search-to-Purchase Conversion Rate: конверсия из использования строки поиска в успешное оформление заказа. В e-commerce качественный семантический поиск дает прямой прирост этого показателя на 15–30%.
• Click-Through Rate (CTR) верхних позиций (1–3): рост кликабельности первых трех позиций подтверждает, что релевантность выдачи стала соответствовать истинному намерению пользователя.
• Длина поисковой сессии до целевого действия: сокращение количества повторных переформулировок запросов и времени до клика на подходящий товар свидетельствует об устранении трения в пользовательском опыте.

Пошаговое руководство по миграции: дорожная карта для CTO и тимлидов

Миграция поискового ядра работающего интернет-магазина — высокорисковая операция. Рекомендуется следовать поэтапному плану с минимальным влиянием на текущие бизнес-процессы.

Этап 1. Аудит поисковых логов и формирование тестовой выборки

Соберите и сегментируйте поисковые логи за последние 3–6 месяцев:

• Выделите топ-20% самых частотных запросов (Head queries), генерирующих основной объем трафика.
• Сформируйте пул запросов из «длинного хвоста» (Long-tail queries): разговорные фразы, опечатки, многословные описания.
• Соберите список запросов с нулевым результатом (Zero-result queries) в текущем Elasticsearch.
• Разметьте эталонную выборку из 1000–2000 запросов с указанием целевых релевантных товаров. Это ваш бенчмарк для проверки гипотез.

Этап 2. Развертывание векторного хранилища и генерация первичных векторов

На основе размера каталога и архитектурных ограничений выберите целевой стек (pgvector для каталогов до 1 млн SKU или Qdrant для высоконагруженных проектов):

• Разверните тестовый инстанс выбранной базы данных.
• Подготовьте пайплайн нормализации каталога и генерации эмбеддингов с помощью проверенной открытой bi-encoder модели.
• Выполните первичную векторизацию всего каталога товаров. Для каталога в 500 000 позиций на современном GPU процесс займет от пары часов до половины суток.
• Сконфигурируйте HNSW-индекс: задайте параметры m (число двунаправленных связей, обычно 16–32) и ef_construction (глубина поиска при построении, обычно 100–200).

Этап 3. Реализация гибридного поиска и алгоритма слияния RRF

Свяжите обе системы в рамках единого сервиса оркестрации поиска (Search Gateway):

• При поступлении запроса параллельно вызываются два бэкенда: лексический поиск (BM25 в Elasticsearch или текстовый поиск PostgreSQL) и векторный поиск (Qdrant или pgvector).
• На этапе векторного поиска накладываются жесткие фильтры по доступности товара и базовым категориям.
• Результаты обеих выдач объединяются через Reciprocal Rank Fusion с константой k = 60.
• На выходе формируется единый ранжированный список кандидатов.

Этап 4. Теневой запуск (Shadow Traffic) и валидация задержек

Перед тем как направлять реальных пользователей на новый поиск, проведите стресс-тестирование в режиме Dark Launch:

• Настройте асинхронное дублирование 100% входящих поисковых запросов с продакшена на новый гибридный поисковый сервис.
• Ответ нового сервиса не отдается клиенту, но логируется в системе телеметрии.
• Измерьте ключевые инфраструктурные показатели: p50, p95 и p99 задержки (целевой p99 для гибридного поиска — не более 50–70 мс), потребление RAM и стабильность инференс-сервиса при пиковых нагрузках.

Этап 5. A/B-тестирование и оценка конверсионного прироста

Переведите 10% пользовательского трафика на новую гибридную систему через сплит-тест:

• Контрольная группа (A): классический поиск на базе BM25 в Elasticsearch.
• Экспериментальная группа (B): гибридный поиск (BM25 + Qdrant / pgvector) с RRF-слиянием.
• В течение 2–3 недель отслеживайте динамику MRR, Zero-Result Rate, CTR и итоговую конверсию из поиска в оплату.
• При подтверждении статистически значимого роста конверсии поэтапно масштабируйте долю трафика: 25% → 50% → 100%.

Этап 6. Эксплуатация, мониторинг и предотвращение дрейфа данных

После полного переключения организуйте регулярный контур поддержки:

• Настройте алерты на всплески пустых поисковых выдач и деградацию времени ответа инференса.
• Обеспечьте постоянный сбор логов запросов без кликов для выявления дрейфа пользовательского словаря (Data Drift).
• Регулярно (раз в квартал) обновляйте тестовый датасет и калибруйте весовые коэффициенты слияния RRF на основе свежих поведенческих данных.

Заключение: векторный поиск как фундамент внутренней оптимизации и GEO

Переход от чисто лексического поиска к гибридному на базе pgvector или Qdrant — это не просто устранение технических задержек в Elasticsearch. Это фундаментальная модернизация ключевого конверсионного узла интернет-магазина. Возврат тех самых потерянных 40% лидов, споткнувшихся о неточную формулировку или разговорный запрос, дает прямой и измеримый эффект на выручку бизнеса без увеличения рекламного бюджета.

Более того, архитектура внутреннего семантического поиска закладывает основу для адаптации сайта к новой эпохе диалоговых поисковых агентов (SearchGPT, Perplexity и поисковых LLM-экосистем). Понимая структуру смысловых векторов своих товаров изнутри, e-commerce проект становится прозрачным, релевантным и готовым к интеграциям с генеративными поисковыми системами будущего.

Cobalt Media проведет предварительный аудит, определит приоритетные направления роста и подготовит прозрачную оценку работ без обещаний гарантированного места в выдаче.

по теме

Услуга и связанный разбор

Стоимость SEO-продвижения↗Бесплатный SEO-Аудит↗