Семантический поиск: как устроен и когда лучше обычного

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

Поэтому честный ответ на вопрос «заменить ли старый поиск» обычно такой: не заменять, а соединить. Гибридный поиск использует оба подхода, а решение о составе принимается по проверке на ваших вопросах. Готовое решение под вашу базу документов описано на странице «Семантический поиск по документам», здесь — устройство и способы проверки.

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

Обычный поиск, который называют полнотекстовым, ищет слова запроса в тексте с учётом форм слова. Он быстр, предсказуем и объясним: видно, какое слово совпало. Но он не знает, что «уволиться», «расторгнуть трудовой договор» и «подать заявление по собственному» — об одном и том же.

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

Как устроен семантический поиск: шесть шагов

Поиск состоит из двух частей. Первая работает заранее и готовит документы, вторая отвечает на каждый запрос.

1. Загрузка. Из файлов, почты, wiki и баз извлекается текст вместе с названием, автором, датой, версией и правами доступа. Сканы сначала проходят распознавание текста.
2. Разбиение на фрагменты. Документ делится на куски, внутри которых мысль завершена. Фрагменту достаются метаданные документа.
3. Эмбеддинги. Модель превращает каждый фрагмент в вектор, в котором близкие по смыслу тексты оказываются рядом.
4. Индекс. Векторы и метаданные записываются в хранилище, которое умеет быстро находить ближайшие векторы.
5. Запрос. Вопрос пользователя превращается в вектор той же моделью, из индекса достаются ближайшие фрагменты, применяются фильтры по правам и метаданным.
6. Ранжирование и показ. Найденное сортируется, при необходимости проходит переоценку, и пользователь получает фрагменты со ссылкой на документ и страницу.

Именно эти шаги лежат в основе ответа «по документам» у языковой модели: перед ответом она получает найденные фрагменты. Эту схему целиком описывает статья «Как устроен RAG-пайплайн», а общую идею — статья «Что такое RAG». Семантический поиск — это та же схема без последнего шага генерации текста.

Разбиение на фрагменты: самое недооценённое решение

Результат поиска сильнее всего зависит не от модели, а от того, как порезаны документы. Слишком мелкие фрагменты теряют контекст: «срок — три рабочих дня» без указания, чего именно. Слишком крупные размывают смысл, и вектор описывает всё сразу, ничего конкретно.

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

Как выбрать размеры, проверяется на ваших вопросах: делаем две-три схемы разбиения и сравниваем результат. Угадать заранее нельзя.

Эмбеддинги: какую модель брать и что с русским языком

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

Практические правила выбора:

• Сравнивать две-три модели на одной выборке ваших вопросов, а не по таблицам рейтингов. Рейтинги составлены на чужих данных.
• Запрос и фрагмент у многих моделей кодируются по-разному: в запросе указывается его роль. Если это пропустить, качество падает без предупреждений.
• Модель запускается в вашем контуре. Для данных ограниченного доступа внешние сервисы эмбеддингов чаще не подходят по требованиям заказчика, поскольку вы отправляете наружу весь текст базы.
• Смена модели означает пересчёт всех векторов: векторы разных моделей несовместимы. Поэтому версию модели записывают в индекс, и переход планируется как отдельная работа.

Дообучать модель эмбеддингов на своих данных стоит, только если сравнение показало, что готовые модели стабильно промахиваются на ваших терминах. Чаще хватает добавить словарь терминов и улучшить разбиение.

Гибридный поиск и переранжирование

Гибридный поиск запускает оба поиска и объединяет результаты. Полнотекстовая часть ловит точные слова, коды и номера, векторная — вопросы своими словами. Оба списка сливаются правилом, которое проверяется на ваших вопросах.

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

Права доступа и актуальность: то, что ломает поиск после запуска

Поиск по документам компании быстро упирается в два вопроса, которые не видны на демонстрации.

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

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

Обе проблемы относятся не к смыслу поиска, а к его эксплуатации. Поэтому в оценку проекта они входят отдельной строкой, а не «как-нибудь потом».

Как проверить поиск: набор вопросов с известными ответами

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

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

Где хранить векторы

Хранилище нужно, чтобы быстро находить ближайшие векторы и фильтровать по метаданным. Выбор определяется объёмом, нагрузкой и тем, что уже есть в вашей инфраструктуре.

• PostgreSQL с расширением pgvector. Подходит, когда база документов умеренная, а PostgreSQL у вас уже работает: одна система, одна копия, права и метаданные рядом.
• Специализированные хранилища. Qdrant и Weaviate разворачиваются у вас и дают больше возможностей для фильтров, гибридного поиска и больших объёмов, ценой ещё одной системы в эксплуатации.
• Облачные сервисы вроде Pinecone. Это внешние сервисы: векторы и метаданные хранятся у поставщика. Для данных ограниченного доступа они чаще не подходят по требованиям заказчика.

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

Что делаем мы и с чего начать

Мы делаем один поиск для одной базы документов: например, регламенты, техническая документация или договоры. Начинаем с обследования: 200 000 ₽ за 2–3 недели при одном-двух источниках, 350 000 ₽ за 3–4 недели при нескольких системах и разных правах. На выходе набор ваших вопросов с ответами, замер текущего поиска, схема разбиения, выбор хранилища и модели, план обновления индекса и вилка бюджета. Сумма вычитается из первого этапа, если продолжаете с нами.

Затем лёгкий пилот на выборке документов стоит 150 000–400 000 ₽ за 2–8 недель, тяжёлый с правами доступа и подключением к источникам — 400 000–1 200 000 ₽ за 2–3 месяца. Вывод в эксплуатацию начинается от 1 500 000 ₽ этапами по 300 000–700 000 ₽. Остановиться можно после любой ступени, исходный код лежит в вашем репозитории с первого коммита. Перечень ступеней и сопровождения — на странице «Тарифы». Если нужен не список фрагментов, а связный ответ со ссылкой на источник, это ассистент по документам, он строится на том же поиске. Пример разбора такой задачи — поиск по технической документации.

Мы не берём поиск по открытому интернету и по неструктурированному архиву без владельца, не настраиваем права в ваших системах за вас и не дежурим круглосуточно.