Семантический поиск: почему подбор по словам не находит ответ
Полнотекстовый подбор сравнивает не смысл, а символы: он разбивает запрос и документы на слова, приводит их к основе и ищет пересечения. Пока сотрудник вводит те же термины, что и автор документа, всё работает. Но стоит сформулировать мысль своими словами — и выдача пустая, хотя нужный файл лежит в базе.
Первый разрыв — синонимы и словоформы. Приведение к основе снимает часть расхождений, но не помогает, когда в запросе «вернуть товар», а в регламенте «отказ от покупки». Пересечения по словам нет — значит, для поиска документ нерелевантен, хотя для человека это один и тот же процесс.
Второй разрыв — формулировка запроса. Вопросы сотрудники задают живым языком, а документы написаны канцеляритом: «кто отвечает за приёмку» против «ответственность за осуществление приёмки». Разные конструкции, разные части речи, нулевое совпадение по словам — и пустая выдача на пятом-шестом запросе заставляет людей искать вручную по папкам.
Семантический поиск работает иначе: он переводит запрос и фрагменты документов в векторные представления и сравнивает их по близости смысла, а не по буквам. Синонимы, словоформы и разные формулировки одной мысли перестают быть барьером. Ниже разбираем, как это устроено и что даёт на документах разного объёма.
Что даёт семантический поиск: эффект в измеримых метриках
Первый замер, который делаем до и после внедрения, — доля запросов, где нужный документ попал в первые результаты выдачи. На корпусе в несколько тысяч страниц поиск по ключевым словам даёт её в пределах 35–45%: формулировка запроса не совпадает с формулировкой в тексте, синонимы и сокращения не находятся. После перехода на смысловой поиск с гибридной схемой — лексический отбор плюс поиск по векторному представлению — показатель поднимается до 75–90%. Работаем на OpenSearch: оба режима живут в одном индексе, вторая система не нужна.
Второй показатель — время до первого полезного документа. Раньше сотрудник тратил 10–20 минут на перебор нерелевантных ссылок или шёл спрашивать коллегу; сейчас выдача по смыслу закрывает вопрос за минуту-две. Следствие видно по повторным обращениям: вопросы вида «где лежит регламент» доходят до носителей знания в разы реже, и это уже изменение нагрузки, а не самооценка удобства.
Отдельно считаем класс отказов «документ есть, но не найден» — когда текст лежит в системе, но поиск по словам его не поднимает из-за другой формулировки или названия раздела. В эталонной выборке такие запросы проваливались примерно в половине случаев и закрывались человеком; после внедрения они находятся в поиске.
Качество выдачи держим под контролем: есть эталонный набор запросов с размеченными правильными документами, по нему считаем метрики до внедрения и после и отдельно смотрим редкие формулировки.
Сравнение подходов: векторный индекс, гибрид и правила
Выбор режима определяет не «качество поиска вообще», а то, какие промахи вы получите на своём корпусе. Векторный индекс находит смысловые совпадения при перефразировке, но теряет точные идентификаторы — номера договоров, артикулы, редкие аббревиатуры. Поиск по правилам предсказуем и объясним, но требует совпадения запроса со схемой.
Гибридный режим снимает это противоречие: он объединяет лексический сигнал и близость эмбеддингов, а фильтры по метаданным отсекают лишнее до ранжирования. Что подходит какому корпусу — в таблице.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Векторный индекс | Разнородный корпус, свободные формулировки запросов, важна устойчивость к синонимам | Требует пересборки при смене модели эмбеддингов, слабо ловит точные коды и редкие термины |
| Гибридный режим | Смешанные запросы: смысл плюс точный идентификатор, несколько типов документов в одном индексе | Нужно согласовать вклад сигналов и порог отсечения, выше время отклика |
| Поиск по правилам | Узкий домен, требование объяснимости и повторяемости, регламентированные запросы | Хрупок к перефразировке, каждое новое поле документа — ручная правка правил |
На практике режим выбирают по составу запросов. Если в корпусе и проза, и точные идентификаторы — начинают с гибрида, а правила оставляют для обязательных условий: доступ, срок, тип документа. Ограничения каждого подхода при этом известны заранее, и выбор режима становится решением по данным, а не по вкусу.
Как мы внедряем: этапы работ от аудита до передачи
Этапы выстраиваем так, чтобы качество поиска измерялось на каждом шаге, а не в конце проекта. Каждый этап заканчивается проверяемым артефактом: отчётом по корпусу, схемой разбиения, набором тестовых запросов.
- Аудит корпуса документов. Считаем объём, форматы, долю сканов и таблиц, находим дубликаты и устаревшие редакции. На выходе — список источников и правило, что попадает в индекс, а что отсекается как шум.
- Схема разбиения и индексирования. Определяем границы фрагментов — раздел, абзац, таблица, — чтобы кусок текста сохранял смысл без соседей. Рядом с фрагментом храним номер пункта, дату, тип документа и права доступа.
- Разметка запросов. Собираем реальные формулировки сотрудников и размечаем их по темам и ожидаемым документам. Это даёт набор проверок, на котором дальше сравниваются варианты поиска.
- Настройка режима выдачи. Ищем баланс между точным совпадением слов и смысловым поиском, задаём фильтры по правам и свежести. Отдельно проверяем короткие запросы и запросы с номером пункта.
- Замер качества. Считаем долю запросов, где нужный документ попал в первую пятёрку результатов, и разбираем провалы вручную. Порог приёмки согласуем до начала работ.
- Опытная эксплуатация и передача. Запускаем на ограниченной группе, смотрим, что ищут и где бросают, правим разбиение и выдачу по факту. Отдаём конфигурации, схему индексирования и регламент переиндексации, обучаем администраторов.
Артефакты на выходе: схемы, словари и регламенты обновления
Семантический поиск остаётся рабочим инструментом только тогда, когда его можно менять без авторов системы. Поэтому передаём не сервис-«чёрный ящик», а комплект артефактов, по которому ваша команда сопровождения сама обновляет корпус, расширяет словари и разбирает инциденты выдачи.
- Схема индексирования — какие поля документа попадают в индекс, на какие фрагменты он режется, с каким перекрытием и какие метаданные (раздел, версия, дата, права) хранятся рядом с текстом.
- Словарь терминов и синонимов предметной области — внутренние аббревиатуры, названия продуктов, профессиональный жаргон; пополняется без пересборки индекса и правок кода.
- Правила предобработки — нормализация разметки, разбор таблиц и вложений, отдельный слой распознавания для сканов: без него часть корпуса просто не находится.
- Политики доступа к разделам — какие коллекции документов кому видны; фильтрация идёт на этапе поиска, а не после него, иначе закрытый документ утекает через выдачу.
- Регламент переиндексации — что обновляется инкрементально при изменении документа, что требует полного прохода, в каком окне это запускается и как проверяется, что новая версия индекса не хуже предыдущей.
- Набор эталонных запросов и метрики качества — контрольные вопросы с ожидаемыми документами; по ним отличите деградацию от разовой жалобы пользователя.
- Эксплуатационная документация — карта сервисов, точки отказа, порядок отката на предыдущую версию индекса, типовые сбои и действия при них.
Пакет передаём вместе с разбором на работающей системе: показываем, как добавить новый раздел документов и как откатиться, если качество выдачи просело после обновления. Дальше сопровождение идёт силами вашей команды или нашей — по вашему выбору.
Кейс: время нахождения ответа в базе документов сократилось
Кейс внедрения: производственная компания с корпусом технической и нормативной документации — десятки тысяч страниц регламентов, паспортов оборудования, инструкций по эксплуатации и внутренних стандартов. Поиск работал по названиям файлов и совпадению слов, поэтому результат зависел от того, угадал ли специалист формулировку.
До внедрения ответ искали ручным перебором: открывали 8-12 документов, сверяли редакции, уточняли у коллег. Среднее время нахождения ответа — 30-40 минут, а примерно каждый пятый запрос заканчивался выводом «в документах нет», хотя нужный пункт существовал в другой формулировке. Нагрузка на профильных специалистов росла: до трети рабочего времени уходило на поиск вместо основной работы.
Что изменили
Документы разобрали по структуре — разделы, пункты, таблицы, приложения — и нарезали на смысловые фрагменты с сохранением ссылки на первоисточник. Семантический поиск собрали как гибридную схему на Elasticsearch: векторные представления отвечают за смысл, точный индекс — за номера, артикулы и аббревиатуры. В выдаче — фрагмент текста и ссылка на страницу оригинала.
Метрики до и после
Доля запросов с найденным ответом выросла с 78% до 96%, среднее время нахождения сократилось с получаса до двух-трёх минут. Нагрузка на профильных специалистов упала примерно вдвое: вопросы, которые закрывались перебором вручную, теперь снимаются самостоятельно. Параллельно расширили обновление индекса — новая редакция документа попадает в поиск в тот же день, и устаревшие версии не всплывают.
Чем отличается векторный индекс от совпадения по словам
Инвертированный индекс отвечает на точное совпадение: запрос разбивается на токены, и документ попадает в выдачу, только если те же токены в нём есть. Это быстро и предсказуемо, но работает лишь когда формулировка известна заранее: «регламент расторжения» не найдёт текст про «порядок прекращения договора». Стемминг и словари синонимов закрывают часть случаев, но не перефразирование, не перевод и не опечатки.
Векторное представление переводит документ и запрос в одно числовое пространство, где смысловое сопоставление считается как близость векторов, а не как совпадение строк. Запрос «как оформить возврат» находит абзацы про «процедуру отмены заказа», хотя общих слов в них нет. Релевантность здесь определяется расстоянием между векторами — выдача ранжируется по смыслу, а не по частоте термина.
Точное совпадение при этом не отменяется. Артикулы, номера договоров, ФИО, коды подразделений и аббревиатуры векторная модель может размыть до похожих по смыслу, но чужих значений, а ошибка тут дороже всего. Такие поля остаются на строковом поиске с обязательным точным вхождением — то же касается юридических формулировок и отрицаний.
В рабочей системе оба механизма собираются в комбинированную выдачу: строковый поиск даёт точные попадания и фильтры, векторный — смысловых соседей, а объединение рангов и веса настраиваются под конкретный корпус. Часть запросов маршрутизируется явно: номерной уходит в точный индекс, вопрос на естественном языке — в векторный. Схему ставим на штатных компонентах, например Qdrant для векторов в связке с инвертированным индексом для строк.
Настройка весов — отдельная работа с разметкой реальных запросов: смотрим, где гибрид проигрывает чистому совпадению по словам, и правим нормализацию рангов, чтобы релевантность росла не на тестах, а на живом потоке обращений.
Частые технические сомнения перед началом работ
Сомнения перед стартом обычно касаются не самой идеи семантического поиска, а того, как он поведёт себя на реальном корпусе: разнородных файлах, сканах, правах доступа и постоянных правках. Ниже — ответы на то, что чаще всего уточняют инженеры и руководители направлений до начала работ.
Что будет с «грязными» документами — таблицами, колонтитулами, разорванными строками?
Перед индексацией текст нормализуется: снимаются повторяющиеся колонтитулы, склеиваются разорванные строки, восстанавливается структура таблиц, документ режется на фрагменты с перекрытием и привязкой к разделу. Тогда шум не попадает в векторное представление и не подмешивается в выдачу при ранжировании.
А если документы — сканы без текстового слоя?
Подключается распознавание: страница приводится к тексту, а каждый фрагмент получает оценку уверенности. Фрагменты с низкой уверенностью помечаются и уходят на ручную проверку — так поиск не начинает уверенно отвечать по мусорному распознаванию. Долю корректно распознанных страниц мы измеряем на пилотной выборке документов заказчика.
Как разграничить доступ, чтобы сотрудник не увидел лишнее?
Права наследуются из источника: файлового хранилища или системы документооборота. Фильтр по доступным пользователю документам применяется до ранжирования, а не после — иначе верх выдачи может оказаться пустым, хотя релевантные материалы есть. В журнале остаётся запрос и область видимости, в которой он выполнялся.
Можно ли развернуть поиск во внутреннем контуре?
Да. Решение разворачивается в закрытом контуре заказчика: модель, индекс и хранилище работают локально, без обращения к внешним сервисам. Обновление — тоже внутренняя процедура.
Что происходит при обновлении базы знаний?
Переиндексация инкрементальная: изменился документ — пересчитывается только он, устаревшие версии помечаются и выпадают из выдачи. Смена модели представлений требует полного пересчёта — это плановая процедура с окном работ, о ней мы предупреждаем заранее.
Как доказать, что качество поиска действительно выросло?
Фиксируем набор реальных вопросов с эталонными фрагментами и считаем долю попаданий в топ-5 и полноту ответа. Тот же набор прогоняется через поиск по ключевым словам — сравнение на одних данных показывает, где именно семантика выигрывает, а где достаточно точного совпадения.
Обсудим задачу: как мы вернёмся с оценкой и планом
Чтобы оценка семантического поиска опиралась на факты, а не на догадки, к первому разговору полезно собрать несколько вводных. Чем точнее исходные данные, тем меньше допущений в плане этапов и тем раньше видно, где именно качество подбора просядет на вашем корпусе.
- Примеры запросов — 15–20 формулировок ваших пользователей, включая опечатки, синонимы и узкие термины предметной области.
- Состав и объём корпуса — типы документов, форматы (PDF, DOCX, сканы, таблицы), примерный объём, языки, есть ли история поиска или ручная разметка.
- Требования к доступу — где разворачиваем контур, нужна ли изоляция без внешних обращений, кто выдаёт учётные записи и согласует сетевые правила.
- Текущие механизмы подбора — как поиск работает сейчас: полнотекстовый индекс, фильтры по полям, ручные подборки, что раздражает пользователей.
- Ожидаемые метрики — доля запросов с релевантным первым результатом, время до ответа, число уточняющих перезапросов.
По итогам обсуждения присылаем оценку работ и план этапов: подготовка корпуса, выбор модели, настройка поиска, проверка на ваших запросах, поставка в контур и передача документации. Опишите задачу — вернёмся с оценкой и планом.
