Почему одного поиска мало

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

Это модельный сценарий, а не отчёт о результатах конкретной фирмы. В исследовании BEIR лексический BM25 оказался устойчивой базовой линией на разнообразных наборах данных; более сложные методы могли улучшать качество, но ценой вычислений. Исследование не доказывает, что гибридный поиск выиграет на русскоязычном каталоге конкретного бизнеса. Вывод скромнее: прежде чем покупать «семантический поиск», сравните его с обычным поиском и измерьте два типа ошибок отдельно.

Разделите точность идентификатора и поиск по смыслу

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

Практичная последовательность запроса выглядит так:

  • Распознать, есть ли в запросе идентификатор, серийный номер или код заказа. Нормализовать пробелы и разделители, но не «исправлять» цифры наугад. Для явного кода сначала сделать точное сравнение по структурированному полю.
  • Параллельно получить кандидатов из полнотекстового поиска по словам и из векторного поиска по смыслу. Оба списка должны проходить одинаковые ограничения по подразделению, клиенту, серии изделия и правам пользователя.
  • Объединить кандидатов по устойчивому ID документа. Reciprocal Rank Fusion (RRF) учитывает позиции результатов в списках, а не смешивает несопоставимые численные оценки разных поисковиков. При необходимости отдельный ранжировщик повторно оценивает короткий список, но добавляет задержку и нагрузку.
  • Отдать человеку ссылки на исходные фрагменты. Генеративная модель подключается только там, где нужен связный ответ; она не должна превращать похожий документ в подтверждение несовместимой запчасти.

Документация Qdrant описывает параллельный предварительный поиск и слияние результатов через RRF. Это возможность инструмента, а не гарантия превосходства любой конкретной конфигурации. Для точных артикулов полезно также предусмотреть отдельное правило: если код найден в справочнике однозначно, не размывать его низкокачественными семантическими совпадениями.

Что делать с существующей инфраструктурой

Новый сервис не обязателен. Если компания уже эксплуатирует PostgreSQL, его полнотекстовый поиск и pgvector позволяют проверить обе ветви в знакомом контуре. В PostgreSQL есть `websearch_to_tsquery` и другие функции для текстовых запросов; pgvector поддерживает точный и приближённый поиск по векторам. У приближённых индексов pgvector фильтрация может применяться после сканирования индекса, поэтому при узких правах доступа нужно отдельно проверять полноту выдачи и настройки индекса.

Если в контуре уже есть Qdrant, можно использовать его гибридный запрос и индексы payload-полей для фильтров. Выбор зависит от текущей эксплуатации, чувствительности данных, объёма, нагрузки и поддержки команды, а не от того, в чьём демо красивее ранжирование. В обоих случаях проверка прав должна происходить до показа результатов и не может полагаться только на инструкцию для LLM. Логи запросов также требуют аккуратного обращения: в них бывают имена клиентов, номера изделий и сведения о неисправностях.

Цена усложнения и проверка на пилоте

Гибридный контур хранит не только тексты: появляются векторы, индекс, метаданные, иногда отдельный ранжировщик и процесс переиндексации. Для ориентира — модельный расчёт: 20 000 документов по пять фрагментов дают 100 000 векторов. При 768 измерениях и 4 байтах на число сырые векторы занимают около 307 МБ. Это не объём готовой базы и не стоимость владения: индексы, текст, метаданные, реплики, резервные копии и запас памяти добавляются сверху. Важнее посчитать часы разметки, обновления каталога и разбора ошибок.

Пилот можно провести на копии разрешённых данных без включения генерации ответов. Соберите, например, 90 реальных вопросов: 30 с артикулами, 30 с описанием симптомов и 30 смешанных. Для каждого человек отмечает правильный документ или честное «ответа нет». Сравните три режима — текстовый, векторный и гибридный — по доле правильных источников в первой пятёрке, ошибкам точного кода, задержке 95-го процентиля и времени проверки оператором. Число 90 — предложенный объём пилота, не статистическая гарантия.

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

Первоисточник по механике гибридного запроса: [документация Qdrant](https://qdrant.tech/documentation/search/hybrid-queries/).