Смысловые векторы нужны поиску, чтобы находить документы, где та же мысль выражена другими словами. Обычный поиск по словам сверяет буквы и словоформы и промахивается, когда запрос и статья называют одно и то же по-разному. Векторный поиск сравнивает не слова, а числовые описания смысла. Поэтому запрос «чем крепить утеплитель к стене» дотянется до статьи «Способы фиксации теплоизоляции на фасаде», хотя общих слов в них почти нет.
Что такое смысловые векторы и почему поиск по словам буксует
Смысловой вектор, или эмбеддинг, — это список чисел, который модель строит, прочитав текст. Обычно в нём несколько сотен или тысяч чисел: у популярных моделей встречается размерность 768 и 1536. Модель обучена так, что близкие по смыслу тексты получают близкие векторы, даже если слова в них разные.
Классический поиск работает иначе. Он проверяет, есть ли в документе те же слова, что в запросе, и оценивает совпадения алгоритмом вроде BM25. Это надёжно для точных формулировок, но ломается на синонимах, перефразах и опечатках. Человек пишет «как утеплить гараж», а в статье стоит «теплоизоляция гаража» — общих слов может не оказаться, и документ не попадёт в выдачу.
Есть и обратная проблема: слово одно, а значений много. Запрос «плитка» на строительном сайте может означать керамическую плитку для ванной, тротуарную плитку или плитку утеплителя. Поиск по словам не различает эти смыслы, если не хватает контекста. Вектор учитывает окружение слов и обычно точнее улавливает, о чём речь.
При этом векторы не отменяют поиск по словам. Для артикулов, моделей и чисел точное совпадение надёжнее. Запрос «шуруп 4х50» по смыслу может выдать «саморез 5х60», а посимвольное совпадение найдёт нужное. На практике оба способа чаще всего работают вместе.
Как поиск превращает текст в вектор
Сначала текст разбивают на части — токены, то есть слова и их фрагменты. Затем энкодер на основе трансформерной модели, например семейства BERT, читает последовательность токенов и выдаёт плотный вектор. «Плотный» здесь значит, что почти каждое число в векторе несёт вклад в смысл, а не просто отмечает наличие слова.
Чтобы сравнить два вектора, считают косинус угла между ними. Значение близко к 1 — тексты по смыслу похожи, близко к 0 — почти не связаны. Косинус удобен тем, что не зависит от длины вектора. Евклидово расстояние, то есть обычная длина отрезка между точками, тоже применяют, но тогда важна нормировка векторов, иначе длинные тексты могут казаться дальше коротких.
Сравнивать запрос со всеми документами напрямую дорого: на 10 000 статей это ещё терпимо, на миллионах — нет. Поэтому строят индекс для приближённого поиска ближайших соседей, ANN. Популярные структуры — HNSW, где соседей ищут по многослойному графу, и IVF, где векторы заранее раскладывают по кластерам. Такой поиск жертвует малой долей точности ради скорости.
В поисковых системах это уже штатная возможность. В Elasticsearch и OpenSearch есть тип поля dense_vector и запросы kNN; документация описывает и настройку индекса, и параметры поиска. Перед внедрением сверяйтесь с актуальной документацией своей версии: детали меняются от релиза к релизу.
Один запрос — два подхода
Возьмём сайт на 10 000 статей и запрос «как выбрать ламинат для тёплого пола». Поиск по словам ищет статьи, где есть «ламинат», «тёплый» и «пол», и находит, скажем, три материала с дословными вхождениями. Векторный поиск считает вектор запроса, сравнивает его с заранее посчитанными векторами всех статей и поднимает наверх пять материалов. Среди них может оказаться «Напольные покрытия с подогревом: что подойдёт» — слова «ламинат» там нет, но смысл тот же.
| Критерий | Поиск по словам (BM25) | Векторный поиск |
|---|---|---|
| На чём основан | Совпадение слов и словоформ | Близость смысловых векторов |
| Синонимы и перефразы | Плохо находит | Находит по смыслу |
| Артикулы, модели, числа | Надёжен | Может ошибаться |
| Что нужно заранее | Индекс слов | Векторы документов и ANN-индекс |
Гибридная схема объединяет обе выдачи. Один из распространённых способов — reciprocal rank fusion, RRF: каждый документ получает балл по своей позиции в каждом списке, баллы складывают и сортируют заново. Документ, который хорошо выступил в обоих списках, оказывается выше. Для каталога стройматериалов это практичный компромисс: точные запросы не теряют артикулы, а описательные находят нужное по смыслу.
Зачем это редакции и SEO-специалисту
Если поиск читает смысл, писать только под точные вхождения ключей уже недостаточно. Важнее попасть в интент — то, что человек хочет решить, и назвать сущности, о которых он спрашивает. Статья про утепление каркасного дома выиграет, если в ней честно разобраны минвата, пенополистирол и условия выбора, а не только повторено «утепление каркасного дома».
- Покрывайте смежные формулировки: «теплоизоляция», «утепление», «фиксация», «крепёж» — в одном материале, если они относятся к делу.
- Стройте структуру: H2 по вопросам читателя, списки шагов, таблицы сравнений. Так смысл материала легче извлечь и человеку, и модели.
- Связывайте статьи перелинковкой по теме: материал про крепёж утеплителя логично ведёт к статье про выбор утеплителя.
- Проверяйте, что страница отвечает на запрос целиком, а не только содержит нужную фразу.
Структура помогает и в другом. Когда абзац отвечает на один конкретный вопрос, его вектор получается более определённым, и поиск точнее понимает, о чём фрагмент. Смешение нескольких тем в одном абзаце размывает смысл.
Где смысловой поиск ошибается
Векторы склонны находить «похожее», а не «нужное». Семантически близкий, но нерелевантный документ может оказаться выше точного. Запрос про крепёж для газобетона рискует получить статью про крепёж для кирпича: тема рядом, а ответ другой.
Качество зависит от модели и данных, на которых её обучали. Универсальная модель может плохо различать строительные термины, если в её обучении их было мало. Кроме того, хранение векторов и ANN-индексов стоит денег и ресурсов: на больших каталогах это заметная статья расходов. Поэтому гибридные схемы остаются стандартом, а не временным решением.
Почему не заменить поиск по словам векторами полностью?
Потому что точные данные — артикулы, размеры, модели — требуют совпадения, а не близости по смыслу. Векторы здесь дают лишние варианты.
Обязательно ли строить свою векторную инфраструктуру?
Нет. Многие поисковые системы и облачные сервисы уже поддерживают dense_vector и kNN-запросы. Начните с проверки возможностей того, что у вас стоит.
Что важнее для попадания в смысловую выдачу?
Полнота ответа на вопрос читателя и ясная структура. Точные вхождения ключей сами по себе уже не решают.
Как понять, что векторный поиск нужен на моём сайте?
Посмотрите на запросы внутреннего поиска, где люди получают пустую или неточную выдачу при явно подходящих статьях. Если таких случаев много, смысловой поиск даст заметную пользу.
Что проверить на своём сайте уже сейчас
Начните с аудита страниц: отвечает ли каждая на свой интент целиком. Затем проверьте внутренний поиск по сайту на синонимах — введите несколько описательных запросов и посмотрите, находит ли он подходящие статьи. Заодно поищите каннибализацию: когда две страницы рубрики ai конкурируют за один и тот же вопрос, читателю и поиску сложнее выбрать нужную.
Следите за обновлениями поисковых API и новостями технологий про эмбеддинги: возможности dense_vector и kNN в вашей версии поисковой системы могут измениться. После проверки решите, что внедрять первым — гибридную выдачу или улучшение структуры материалов.