Семантический поиск vs полнотекстовый: три embedding-модели на 10 000 категорий

2026: семантический поиск vs полнотекстовый — три embedding-модели на 10 000 категорий

Классический полнотекстовый поиск в PostgreSQL работает быстро и предсказуемо — до тех пор, пока пользователь не задаст запрос, который «не бьётся» по лексемам. Семантический поиск на основе embedding-моделей обходит это ограничение: он понимает смысл запроса, а не просто совпадение слов. Разберёмся, как оба подхода работают в реальном эксперименте на 10 тысячах категорий Ozon, и какие embedding-модели лучше справляются с русским языком.

Как работает полнотекстовый поиск в PostgreSQL

Полнотекстовый поиск строится на двух типах данных: tsvector (нормализованный текст документа) и tsquery (нормализованный запрос). PostgreSQL выполняет лемматизацию — приводит слова к словарной форме, удаляет стоп-слова и затем сравнивает наборы лексем. Ранжирование через ts_rank учитывает частотность совпадений.

На датасете из 10 019 категорий товаров медианная латентность полнотекстового поиска составила 1,3 мс. Это в разы быстрее любого embedding-подхода. Но у метода есть фундаментальные проблемы: он не понимает синонимов («велик» ≠ «велосипед»), не работает с разговорной лексикой, не умеет искать кросс-лингвистически и не распознаёт намерения пользователя.

Семантический поиск: embedding-модели и векторные базы

Идея семантического поиска проста: каждый документ и каждый запрос превращаются в числовой вектор (embedding) фиксированной размерности. Близкие по смыслу тексты получают близкие векторы в пространстве. Для поиска используется косинусное расстояние — чем меньше угол между векторами, тем выше релевантность.

В эксперименте использовалось расширение pgvector для PostgreSQL, которое позволяет хранить векторы прямо в базе данных. Для ускорения поиска создаётся IVFFlat-индекс, разбивающий векторное пространство на кластеры. В продакшене с миллионами записей рекомендуется HNSW-индекс — он даёт лучшую точность за счёт большего потребления памяти.

Три embedding-модели: характеристики

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

• Qwen3-Embedding-0.6B (Alibaba) — размерность 1024, развёртывается локально через Hugging Face Text Embeddings Inference на GPU. Мультиязычная, компактная, бесплатная.
• GigaChat EmbeddingsGigaR (Сбер) — размерность 2560, доступна через API. Специально обучена на русском языке, включая разговорную речь.
• OpenAI text-embedding-3-small — размерность 1536, доступна через API. Мультиязычная, наиболее распространённая на рынке.

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

Результаты эксперимента: синонимы и разговорная лексика

Запрос «лекарства» — в данных нет этого слова, но есть категория «Аптека». GigaChat точно нашёл «Лекарственные средства» с score 0,92. Qwen3 промахнулся (канцелярия, 0,66), OpenAI выдал нерелевантный результат (0,31). Полнотекстовый поиск — ноль результатов.

Запрос «велик» (разговорное «велосипед»). GigaChat — единственная модель, которая поняла связь: «Спорт и отдых / Велосипед» с score 0,89. Остальные модели и полнотекстовый поиск потерпели неудачу.

Intent-запросы: понимание ситуации

Запрос «у меня протекает кран» — ситуация, а не товар. GigaChat определил «Сантехника / Смеситель» (score 0,79) и дал ещё четыре релевантных результата. Qwen3 ушёл в бытовую технику, OpenAI — в канцелярию. Полнотекстовый поиск вернул пустоту.

Запрос «первый раз завожу кота». GigaChat предложил «Когтеточка», «Антицарапки», «Антицарапки» (0,71) — именно то, что нужно новоиспечённому котовладельцу. OpenAI хотя бы зацепился за корма для кошек (0,31).

Кросс-языковые запросы

И Qwen3, и GigaChat точно перевели «gaming mouse» в «Игровая мышь» (score 0,73 и 0,90 соответственно). «DIY tools» обе модели корректно отнесли к строительным инструментам (score ~0,78–0,79). OpenAI на обоих запросах показала значительно более низкие результаты.

Латентность: кто быстрее

Полнотекстовый поиск — вне конкуренции: медиана 1,3 мс. Среди embedding-моделей локальный Qwen3 на GPU показал 21 мс — в 8 раз быстрее GigaChat (168 мс) и в 12 раз быстрее OpenAI (275 мс). Разница объяснима: локальный инференс против сетевых API-вызовов.

Для RAG-систем (Retrieval-Augmented Generation — подход, где LLM получает контекст из векторной базы перед генерацией ответа) критична как точность поиска, так и скорость. Локальные embedding-модели дают лучший баланс между качеством и латентностью.

Итоги: какую модель выбрать

Для русскоязычных проектов GigaChat EmbeddingsGigaR показала лучшее качество по всем параметрам: синонимам, разговорной лексике, intent-запросам и кросс-языковому поиску. Однако она требует отправки данных в облако Сбера и платная.

Qwen3-Embedding-0.6B — лучший выбор для проектов, где важна конфиденциальность и нулевая стоимость. На кросс-языковых задачах она сопоставима с GigaChat, но на синонимах и intent-запросах значительно уступает.

OpenAI text-embedding-3-small на коротких русскоязычных текстах оказалась худшей из трёх. Однако важно помнить: модель обучена преимущественно на английском корпусе, и на более длинных текстах результаты могут быть лучше.

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