Умный поиск с пониманием смысла запроса (семантический поиск)

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

В этой статье разберём, как устроен семантический поиск с пониманием смысла запроса: чем он отличается от полнотекстового, что такое эмбеддинги и векторная база, почему на практике выигрывает гибридный подход и как всё это внедрить в каталог на 1С-Битрикс без перегрузки сервера. Если вы хотите оценить готовность своего проекта к таким доработкам, начните с аудита и оптимизации 1С — он показывает, где узкие места в данных и обмене.

Проблема «поиск ничего не нашёл»

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

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

Как работает обычный поиск и где ломается

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

Ломается он на нескольких типовых ситуациях:

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

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

Что такое семантический поиск

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

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

Эмбеддинги и векторная база

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

1. Индексация. Каждый товар (название, описание, свойства) превращается в вектор и сохраняется в векторной базе.
2. Запрос. Поисковую фразу покупателя тоже превращают в вектор.
3. Поиск ближайших. В векторной базе находят товары с наименьшим расстоянием до вектора запроса.
4. Ранжирование. Ближайшие по смыслу товары показывают первыми, при необходимости смешивая с точными совпадениями.

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

Гибридный поиск: лучшее из двух миров

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

Правильная стратегия — определить тип запроса и направить его в подходящий механизм или объединить результаты с приоритетом. Если запрос похож на код — приоритет точному совпадению; если это описательная фраза — работает семантика; фильтры и характеристики применяются поверх. Как строить точную часть, мы разбираем в материалах про поиск по артикулу и эффективную работу с данными через D7 ORM, а смысловую надстройку добавляют поверх неё.

Синонимы, опечатки и намерение

Семантический поиск естественным образом решает задачи, которые в классическом поиске требовали ручных словарей.

• Синонимы. Близкие по смыслу слова дают близкие векторы, поэтому «кеды» находят кроссовки без словаря синонимов.
• Опечатки. Небольшие искажения слабо меняют вектор, и запрос всё равно попадает в нужную область; дополнительно подключают исправление опечаток.
• Намерение. «Что подарить бабушке» — это про подбор, и семантика находит подарочные категории, а не буквально слово «бабушка».
• Разные формулировки. «Дешёвый», «недорогой», «бюджетный» воспринимаются как один смысл.

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

Архитектура на 1С-Битрикс

1С-Битрикс не имеет встроенного семантического поиска, поэтому его добавляют как отдельный слой поверх каталога. Архитектурно это выглядит так:

1. Источник данных. Товары живут в инфоблоках и торговом каталоге, откуда берутся название, описание и свойства для индексации.
2. Сервис эмбеддингов. Внешний по API или локальная модель превращает тексты товаров и запросы в векторы.
3. Векторная база. Отдельное хранилище векторов с быстрым поиском ближайших соседей.
4. Слой поиска. Компонент на сайте принимает запрос, определяет тип, обращается к нужному механизму и собирает выдачу.
5. Витрина. Результаты показываются в привычном интерфейсе поиска и каталога с ценами и наличием.

Обращения к внешним сервисам эмбеддингов и к векторной базе строят через аккуратный интеграционный слой, чтобы витрина не зависела от сбоев внешних систем и при их недоступности откатывалась к обычному поиску. Принципы безопасной работы с внешними API и вебхуками мы описываем в статье про REST, вебхуки и безопасность в Битрикс.

Индексация и обмен с каталогом

Качество семантического поиска напрямую зависит от того, насколько актуальны векторы товаров. Каталог живёт: приходят новые позиции, меняются названия и описания при обмене с 1С. Индекс должен успевать за этими изменениями.

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

Здесь снова всё упирается в качество обмена с учётной системой: если данные товаров приходят нестабильно, страдает и поиск. Поэтому надёжный обмен CommerceML и корректные свойства товаров — фундамент, на который ложится семантический слой. Настроить этот фундамент помогает автоматизация продаж и склада на 1С.

Производительность и стоимость

Распространённый страх — что «умный поиск с ИИ» ляжет тяжёлым грузом на сервер и бюджет. На деле нагрузку легко удержать при правильной архитектуре.

• Основная нагрузка разовая. Тяжёлое — это построение векторов при индексации, и оно вынесено в фон, а не в момент запроса.
• Поиск быстрый. Поиск ближайших векторов в специализированной базе работает быстро даже на сотнях тысяч товаров.
• Кэширование запросов. Частые запросы и их результаты кэшируются, снижая обращения к внешним сервисам.
• Контроль стоимости эмбеддингов. Если векторы берутся по API, пересчитывают только изменённое, а не весь каталог.

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

Как измерять качество поиска

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

• Доля пустых выдач. Главный показатель проблемы; семантика должна её резко снижать.
• Конверсия из поиска. Сколько поисковых сессий заканчивается добавлением в корзину и заказом.
• Клики по результатам. Кликают ли по верхним позициям — признак релевантности ранжирования.
• Уточнения запроса. Если люди постоянно переформулируют запрос, поиск их не понимает.

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

Частые ошибки

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

Чек-лист внедрения

1. Данные готовы. Названия, описания и свойства товаров заполнены и стабильно приходят обменом.
2. Выбран источник эмбеддингов. Внешний API или локальная модель с учётом приватности и бюджета.
3. Векторная база поднята. Отдельное хранилище с быстрым поиском ближайших соседей.
4. Гибрид настроен. Точное совпадение, полнотекст, семантика и фильтры работают вместе с приоритетами.
5. Индексация инкрементальная. Изменённые товары переиндексируются фоном при обмене с 1С.
6. Откат предусмотрен. При сбое внешнего сервиса поиск деградирует к обычному, а не падает.
7. Кэш и лимиты. Частые запросы кэшируются, пересчёт векторов ограничен изменениями.
8. Метрики настроены. Доля пустых выдач, конверсия и переформулировки измеряются.

Вывод

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

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